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(57) Abstract: The invention relates to a method lor implementing an op- 
erating and observation system for field devices (FGI -FGN). A server de- 
vice (HS1 -HSN) is provided in each field device and the field devices are 
connected to a proxy server device (1 ). Said proxy server device is con- 
nected to a user device (Nl-NN) on which a browser device is installed. 
The proxy server device interrogates the field devices in order to automat- 
ically identify the field devices which are connected to the proxy server 
device, and allocates a network address to each field device. A basic in- 
formation message is produced by the proxy server device, said informa- 
tion message comprising specific electronic information about each field 
device, based on the results of the interrogation thereof. The respective 
electronic information comprises link information concerning the respec- 
tive server device of each field device, such that after the basic informa- 
tion message has been transmitted to the user device, respective device 
information messages are emitted in a graphical manner, by means of the 
browser device, for the observation/operation of the field devices. Said 
device information messages can be requested from the respective server 
devices of the field devices. 

(57) Zusammenfassuiig: Die Erfindung betrifft ein Verlahren zur Inbe- 
triebnahme eines Bedien-und Beobachtungssystems fur Feldgerate (FG1- 
FGN), wobei in den Feldgeraten jeweils eine Ser\'ereinrichtung (HS1- 
HSN) ausgebildet ist und die Feldgerate an eine Proxy -Serve reinrichtung 
(I) angeschlossen sind und wobei die Proxy-Servereinrichtung mit einer 
Nutzereinrichtung (Nl-NN) verbunden ist, auf welcher eine Browser- Ein - 
richtung installiert ist. Es wird durch die Proxy-Servereinrichtung eine 
Abfrage der Feldgerate zum automatischen Erkennen der an die Proxy- 
Servereinrichtung angeschlossenen Feldgerate ausgefuhrt und eine jewei- 
ligen Netzwcrkadresse fur die Feldgerate vergeben. Eine Basisinforma- 
tion wird durch die Pro xy-Serve reinrichtung erzeugt, wobei die Basisin- 
formation in Abhangigkeit von der Abfrage der Feldgerate jeweilige elek- 

[Fortsetzung auf der nachsten Seite] 
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Informationcn uber die Feldgerate umfasst und wobei die jcweiligen elektronischen lnformationen eine Link -In formation auf die 
jeweilige Servereinrichtung der Feldgerate so umfassen, dass nach einem Ubermitteln der Basi sin formation an die Nutzereinrichtung 
mit Hilfe der Browser-Einrichtung jeweilige Gerateinforrnalionen zum Beobachten/Bedienen der Feldgerate grafisch ausgegeben 
werden, die von der jeweiligen Servereinrichtung der Feldgerate abrufbar sind. 
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Beschreibung 

Verfahren zur Inbetriebnahme eines Bedien- und 
Beobachtungssystems von Feldgeraten 

5 

Die Erfindung liegt auf dem Gebiet des f erngesteuerten 
Betreibens von Feldgeraten, insbesondere zum Zweck des Beo- 
bachtens und Bedienens von Feldgeraten, beispielsweise in e- 
nergietechnischen Anlagen. 

10 

Feldgerate werden im Rahmen der Automat isierung von verschie- 
densten technischen Prozessen genutzt, beispielsweise zum U- 
berwachen eines Produktions- bzw. Herstellungsprozesses oder 
eines Verarbeitungsprozesses . Bei den Feldgeraten kann es 
15 sich urn die Produktionsanlagen selbst oder urn Gerate zum U- 
berwachen, vorzugsweise zum Steuern und/oder zum Regeln in 
Abhangigkeit von erfassten Felddaten, der eingesetzten tech- 
nischen Produktionsmittel bzw. -anlagen handeln. 

20 Beim Bedienen der Feldgerate im Einsatz konnen grundsatzlich 
zwei Arten der Bedienung unterschieden werden. Einerseits 
konnen die Feldgerate vor Ort mittels Betatigung der vorgese- 
hen Bedienelemente betatigt werden. Hierbei muss sich der Be- 
diener am Feldgerat befinden oder zur entsprechenden Anlage 

2 5 fahren. Andererseits gehort die Fernbedienung von Feldgera- 

ten aus Uberwachungs- " und Wartungszentralen zum bekannten 
Stand der Technik. Standard- Terminalprogramm, die hierbei 
zur Bedienung der Feldgerate eingesetzt werden, stellen dem 
•Bediener nur einen sehr geringen. Komfort zur Verfugung und 

3 0 gestatten in der Regel nur einfache Bedienhandlungen . Insbe- 

sondere grafisch aufbereitete Inf ormationen, beispielsweise 
Messdaten, lassen sich nicht fur den Bediener darstellen. 
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Es wurden deshalb komplexe Bedienprogramme fur die Fernbedie- 
nung der Feldgerate entwickelt. Solche komplexen Bedienpro- 
gramme nuissen auf dem jeweiligen Feldgerat installiert werden 
und belegen so Speicherbereiche , die fur die Gerateanwendung 
5 nicht mehr zur Verfugung stehen. Daruber hinaus benotigt je- 
der Bediener das fur das jeweilige Feldgerat erf orderliche 
Bedienprogramm. Bei Feldgeraten verschiedener Hersteller o- 
der Feldgeraten des gleichen Herstellers mit unterschiedli- 
chen Ausgabestanden konnen relativ schnell eine Vielzahl von 
10 Programmen oder Programmver s ionen benotigt werden. 

In Verbindung mit den bekannten Bedienverf ahren entsteht ein 
erheblicher Auf wand bei der Parametrierung der Feldgerate, 
die vor der Inbetriebnahme der bekannten Bedien- 
15 / Beobachtungs sys t erne notwendig ist. 

Feldgerate werden ublicher Weise mit einer Standardparameter- 
einstellung ausgelief ert . Diese Standardparameter konnen von 
einem Nutzer/Bediener vor Ort am Gerat verandert werden, wo- 

20 bei schon bei einer Veranderung von wenigen Parametern auf- 

grund der oftmals eingeschrankten Anzeigemoglichkeiten am Ge- 
rat der Uberblick tiber Standardparameter bzw. geanderte Para- 
meter verloren geht . Komplexe PC-Bedienprogramme , die eine 
ubersichtliche, graf ische Aufbereitung der Parame- 

25 ter/Parametergruppen sowie eine Speicherung/Archivierung der 
Parameter bieten, weisen den Nachteil auf, dass durch Gerate- 
und/oder Programmversionen schnell der Uberblick verloren 
geht. Dieses Problem verstarkt sich besonders dann, wenn ein 
Anwender verschiedene derartige Gerate im Einsatz hat , die 

3 0 jeweils andere Bedienprogramme oder andere Vers ionen des 
gleichen Bedienprogramms erfordern. 



BNSDOCID: <WO 03036400A1_I_> 



WO 03/036400 PCT/DE02/03849 



3 

Aufgabe der Erfindung ist es, eine verbesserte Moglichkeit 
zur Vorbereitung einer Inbetriebnahme bei der Fernbedienung 
von Feldgeraten zu schaffen, die fur verschiedene Feldgerate- 
typen flexibel einsetzbar ist und bei der mit der Inbetrieb- 
5 nahme verbundene Aufwand vermindert ist. 

Die Aufgabe wird erf indungsgemaS durch das Verfahren nach An- 
spruch 1 gelost. 

10 Mit der Erfindung wird ein Verfahren vorgeschlagen, welches 
die Inbetriebsetzung eines Bedien- und Beobachtungssystems 
ohne vorherige Parametrierung der Systemkomponenten gestat- 
tet. Die Proxy-Servereinrichtung erkennt die angeschlossenen 
Feldgerate und deren Alarmstatus. Diese Inf ormationen werden 

15 auf einer vorzugsweise dynamisch erzeugten Homepage auf der 

Nutzereinrichtung mittels eines Links auf eine Seite der Ser- 
vereinrichtung des jeweiligen Feldgerate verof f entlicht . Die 
Servereinrichtung der angeschlossenen Feldgerate beinhalten 
jeweils die speziell auf das jeweilige Feldgerat zugeschnit- 

20 tenen Inf ormationen (HTML- Seiten/ Java-Archive) fur die Bedie- 
nung des Feldgerats . Hierdurch reduziert sich die Paramet- 
rierung des Bedien- und Beobachtungssystems im wesentlichen 
auf die Vergabe der Net zwerkadressen fur die angeschlossenen 
Feldgerate . 

25 

Die mittels der Proxy-Servereinrichtung in Abhangigkeit von 
der Abfrage erzeugte Homepage wird in der (den) Nutzereinrich- 
tung (en) mit Hilfe der Browser-Einrichtung ausgegeben . 

30 Bei einer vorteilhaf ten Weiterbildung der Erfindung ist vor- 
gesehen, dass die Basisinf ormationen in einer Speicherein- 
richtung der Proxy-Servereinrichtung gespeichert wird, wo- 



BNSDOCID: <WO O3O364O0A1_l_> 



WO 03/036400 



PCT/DE02/03849 



4 

durch die Basisinf ormationen fur den anschliefienden Betrieb 
des Bedien- und Beobachtungs systems gesichert sind. 

Eine vorteilhafte Ausgestaltung der Erfindung sieht vor, dass 
5 die Basisinf ormationen eine jeweilige Alarmstatusinf ormation 
fur die Feldgerate umfassen. Diese Alarmstatusinf ormation 
gewahrleistet einen schnellen Uberblick uber den Status aller 
Gerate einer Anlage, ohne alle verfugbaren Inf ormationen 
(Meldungen, Storungen, Messwerte. . . ) anzuzeigen. Die Alarm- 
10 statusinformation wird vorzugsweise durch ODER-Verkniipf ung 

der fur die geeignet f estzulegenden Stati relevanten Informa- 
tionen gebildet (z.B. Ampel : rot - Storsammelmeldung : Hard- 
warefehler, Betriebsstorung; gelb - Warns ammelmel dung ; grun - 
keine Warnungen/Storungen) . Ein Anwender kann nun mit einem 
15 Blick auf die Statusinformation der Gerate erkennen, ob er 
Detailinf ormationen von den Geraten benotigt und muss diese 
Detailinf ormationen nur noch auswerten, wenn die Alarmstatus- 
inf ormation eine entsprechende Anzeige liefert. 

Bei einer bevorzugten Fortbildung der Erfindung kann vorgese- 
hen sein, dass die Basisinf ormationen elektronische Daten zum 
automatischen Erzeugen eines grafisch ausgebbaren Bedienbaums 
mittels der Browsereinrichtung nach dem Ubermitteln der Ba- 
sisinf ormation von der Proxy-Servereinrichtung an die Nutzer- 
einrichtung umfassen, wodurch eine einfache und fur den Be- 
diener leicht zu uberblickende Form der Darstellung der tech- 
nischen Ebenen in den Feldgeraten sowie zwischen den Feldge- 
raten geschaffen ist. 

3 0 Eine zweckmaSige Weiterbildung der Erfindung sieht vor, dass 
die Abfrage der Feldgerate durch die Proxy-Servereinrichtung 
zum automatischen Erkennen der an die Proxy-Servereinrichtung 
angeschlossenen Feldgerate mit Hilfe einer ^broadcast v - 
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Anfrage ausgefuhrt wird. Bei einer „ broadcast 
Konf igurationsabf rage wird in alien Feldgeraten des gesamten 
Netzwerksegmentes der in den Feldgeraten integrierte Dienst 
zur Abfrage der Geratekonf iguration aktiviert. Daraufhin sen- 
5 den alle Feldgerate in diesem Segment ihre Konf igurationsda- 
ten an den Ausloser der Konf igurationsabf rage . 

Das Verfahren kann vorteilhaft zum Uberwachen/Bedienen ener- 
gietechnischer Anlagen verwendet werden, die haufig ortlich 
10 verstreut angeordnet sind. 

Das Verfahren und/oder die Vorrichtung konnen vorteilhaft zum 
iirberwachen energietechnischer Anlagen verwendet werden. 

15 Die Erfindung wird im folgenden anhand von Ausf uhrungsbei- 

spielen unter Bezugnahme auf eine Zeichnung naher erlautert . 
Hierbei zeigen: 

Figur 1 eine schematische Darstellung mit einem Geratenetzwerk 
2 0 und einem Firmen- Intranet , die uber einen Proxyserver 

verbunden sind; 

Figur 2 eine Oberf lachengestaltung einer Browser- 

Einrichtung mit grafischen Darstellungen fur mehre- 
2 5 re Feldgerate; 



Figur 3 eine andere Oberf lachengestaltung der Browser- 

Einrichtung mit einer grafischen Darstellung einer 
Frontansicht eines Feldgerats; 

30 

Figur 4 eine schematische Darstellung eines Feldgerats und 
eines Nutzer-Personalcomputers ; 



BNSDOCID: <WO 03036400A1_L> 



WO 03/036400 PCT/DE02/03849 



6 

Figur 5 ein Ablauf diagramm fur ein Herunterladen von HTML- 
Seiten im Rahmen eines Beobachtungs- und Bediensys- 
tems ; 

5 Figur 6 ein Blockdiagramm zum Erlautem eines RPC-Auf ruf s ; 

Figur 7 eine Darstellung der Anordnung mit dem Geratenetz- 
werk und dem Firmen- Intranet nach Figur 1, wobei 
einzelne Elemente des Proxyservers schematisch ge- 
10 zeigt sind; 

Figur 8 eine schematische Blockdarstellung des Proxyser- 
vers ; 

15 Figur 9 eine schematische Darstellung zur Erlauterung einer 
Client /Server- Interakt ion; 

Figur 10 eine schematische Darstellung zur Erlauterung einer 
Gerateerkennung in einer Master/Slave-Anordnung; 

20 

Figur 11 ein Nassi-Sneider-Diagramm; 

Figur 12 eine schematische Baumdarstellung eines Verfahrens 
zur Gerateerkennung; 

25 

Figur 13 eine schematische Darstellung einer Master/Slave- 
Anordnung zur Erlauterung einer Konf igurationsab- 
f rage; 

3 0 Figur 14 ein schematische Blockdarstellung einer Geratver- 
waltung im Proxyserver; 
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Figur 15 eine schematische Blockdarstellung zur Erlauterung 
der f unktionellen Einbindung eines XSL-Parsers in 
dem Proxyserver (XSL - „ Extended Stylesheet Langua- 
ge w ) ; und 

Figur 16 eine schematische Blockdarstellung zur Erlauterung 
eines XSLT-Prozessors (XSLT - „ Extended Stylesheet 
Language Transformations") . 

Im folgenden wird ein in Verbindung mit Feldgeraten nutzbares 
sogenanntes Beobachtungs- und Bediensystem (BuB-System) be- 
schrieben. 

Figur 1 zeigt eine schematische Architektur von zwei Netzwer- 
ken, ein Geratenetzwerk mit mehreren Feldgeraten FG1 . . . FGN 
und ein Firmen- Intranet mit mehreren Nutzereinrichtungen 
N1...NN, vorzugsweise Personalcomputer (PC).. Das Geratenetz- 
werk und das Firmen- Intranet sind uber einen Proxyserver 1 
verbunden. Der Proxyserver 1 ist Bestandteil des Beobach- 
tungs- und Bediensystems und dient als ein Gateway zwischen 
dem Geratenetzwerk und dem Firmen- Intranet . Mit Hilfe des 
BuB- Systems werden einerseits Inf ormationen, beispielsweise 
Mess- und/oder Zustandsdaten, von den Feldgeraten FG1...FGN 
erfasst und an die Nutzereinrichtungen N1...NN ubermittelt, 
urn einen Benutzer der Nutzereinrichtungen N1...NN uber den 
Betriebszustand der Feldgerate FG1...FGN zu informieren. An- 
dererseits dient das BuB-Systems zum Erfassen von Bedien- 
bzw. Steuereingaben des Benutzers mit Hilfe der Nutzerein- 
richtungen Nl . . . NN und zum Umsetzen der Eingaben des Benut- 
zers in den Feldgeraten FG1...FGN. Bei den Feldgeraten 
FG1...FGN kann es sich urn beliebige Gerate zum Beobachten, 
zum Messen, zum Steuern und/oder zum Regeln verschiedenster 
physikalischer GroEen in unterschiedlichen technischen Pro- 
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zessen handeln, beispielsweise zum Uberwachen und/oder Steu- 
ern energietechnischer Anlagen, beispielsweise eines Umspann- 
werks . 

5 Das Geratenetzwerk umfasst einzelne PPP-Verbindungen 2 (PPP - 
„ Point to Point Protocol") , die uber einen Sternkoppler 3 mit 
dem Proxyserver 1 verbindbar sind, oder ein separates Ether- 
net-Segment. Der Proxyserver 1 stellt eine eigene Homepage 
in Form von HTML-Daten (HTML - „HyperText Markup Language *) 
10 zur Verfugung, die eine Ubersicht uber die in dem Geratenetz- 
werk erreichbaren Feldgerate FG1...FGN zeigt (vgl . Figur 2); 
die Homepage kann mit Hilfe eines Standard-Browsers in den 
Nutzereinrichtungen Nl . . . NN dargestellt werden. 

15 GemaS Figur 1 sind die Feldgerate FG1...FGN nur mit dem 

Sternkoppler 3 und einem daran angeschlossenen Modem 4 aus- 
gestattet. In diesem Fall sind die Feldgerate FG1 . . . FGN liber 
eine asynchrone serielle Schnittstelle direkt uber den Stern- 
koppler 3 mit dem Modem 4 verbunden. Es sind verschiedene 

2 0 Formen der Ankopplung uber aktive und passive Sternkoppler 

moglich. Als Protokoll fur den Zugriff auf die Feldgerate 
FG1...FGN wird ein IP-Protokoll (IP - ^Internet Protocol") 
uber eine PPP-Linkschicht verwendet. 

25 Wenn die Feldgerate FG1...FGN mit einem Ethernet -Anschluss 
ausgestattet sind, sind die Ethernet-Anschlusse mit einem 
Switch oder einem Hub verbunden. Besitzt dieser Switch oder 
dieser Hub neben Ethernet -Ports auch einen PPP-Port, dann 
spricht man von einem Router. Dieser PPP- Port kann dann eben- 

3 0 falls direkt mit dem Modem 4 verbunden werden. 

Im Firmen- Intranet haben die an das lokale Netz angeschlosse- 
nen Nutzereinrichtungen N1...NN Zugang zu einem Modem 5, wel- 
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ches iiber ein Telekommunikationsnetz 6, beispielsweise ein 
Telefonnetz auf Basis eines ISDN- oder eines Mobilfunk- 
Netzes, mit dem Modem 4 des Geratenetzwerk verbindbar ist. 
Wird in den Nutzereinrichtungen N1...NN jeweils eine DFU- 
5 Verbindung (DFU - Datenf ernubertragung) eingerichtet , kann 
von den Nutzereinrichtungen N1...NN aus jeweils ein Zugriff 
auf die Feldgerate FG1 . . . FGN erfolgen. Wird nun der Proxy- 
server 1 von den Nutzereinrichtungen N1...NN angesprochen, 
kann von jeder der an das Firmen- Intranet angeschlossenen 

10 Nutzereinrichtungen Nl . . .NN auf die Feldgerate PG1...FGN zum 
Beobachten und Bedienen zugegriffen werden. Der Proxyserver 
1 „spiegelt" alle Feldgerate FG1...FGN, d.h. Inf orrnationen 
iiber die Feldgerate FG1...FGN, ins Firmen- Intranet . Dazu 
werden vom Proxyserver 1 die folgenden Protokolle verarbei- 

15 tet: HTTP-Protokoll (HTTP - ^Hypertext Transfer Protocol" und 
RPC-Protokoll (RPC - „Remote Procedure Call 14 ) . Das HTTP- 
Protokoll dient zur Ubertragung statischer Daten. Hierbei 
handelt es sich urn Daten, die nur einmalig an den Proxyserver 
1 ubertragen werden und anschliefiend dort in einem Dateispei- 

20 cher fur spatere Abrufe durch die Nutzereinrichtungen N1...NN 
abgelegt werden. Das RPC-Protokoll , welches ebenfalls ein 
IP-basiertes Protokoll ist, wird zum Ubertragen "dynamischer 
Daten genutzt. Bei den dynamischen Daten handelt es sich 
insbesondere urn in den Feldgeraten FG1 . . . FGN erfasste Mess- 

25 werte und/oder Ereignislisten, betreffend Inf orrnationen uber 
Ereignisse in den Feldgeraten FG1 . . .FGN. 

Das HTTP-Protokoll gestattet den Nutzereinrichtungen N1...NN 
den Zugriff auf die Feldgerate FG1...FGN. Bei einem Zugriff 
30 im Rahmen des BuB-Systems werden zunachst mittels der Anwahl 
der zugehorigen IP-Adresse des zu bedienenden/beobachtenden 
Feldgerats HTML-Daten von dem Feldgerat an die in diesem An- 
wendungsf all genutzte Nutzereinrichtung ubermittelt, wobei 
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die HTML -Da ten Daten umfassen, mit deren Hilfe in der Brow- 
ser-Einrichtung der abrufenden Nutzereinrichtung eine Dar- 
stellung des Feldgerats erzeugt werden kann, wie dies bei- 
spielhaft in Figur .3 dargestellt ist. Der Abruf der HTML- 
Daten zum Erzeugen der Darstellung gemaS Figur 3 kann mit 
Hilfe einer Auswahl eines der in Figur 2 in der Ubersicht 
darges tell ten Feldgerate durch den Benutzer ausgelost werden, 
beispielsweise mittels der Betatigung einer Maus oder einer 
Tastatur der Nutzereinrichtung. 

GemaS Figur 3 sind auf der Oberflache 2 0 der Browser- 
Einrichtung die folgenden Inf ormationen dargestellt (vgl. 
linke Seite in Figur 3): Feldgeratef amilie (z.B. SIPROTEC4) , 
Feldgerateart und Feldgeratetyp 21, ein Bedienbaum 22, die 
Version des BuB-Tools 23 (Version und Datum) und Angaben zur 
Verbindung 24 mit dem Feldgerat (MLFB - „Maschinenlesbare 
Fabrikationsbezeichnung", BF-Nummer, Verbindungsstatus und 
IP-Adresse) . Auf der Oberflache ist weiterhin die einem Link 
bzw. Zweig im Bedienbaum 22 zugeordnete HTML-Seite 25 ange- 
zeigt. In Abhangigkeit von dem im Bedienbaum 22 ausgewahlten 
Link wird die zugehorige HTML-Seite 25 auf der Oberflache 20 
der Browser-Einrichtung dargestellt. 

Die in den Feldgeraten FG1...FGN abgelegten HTML-Seiten, d.h. 
auch die zur Erzeugung der in Figur 3 gezeigten Darstellung 
genutzte HTML-Seite 25, konnen Java-Code umfassen, der die 
Browser-Einrichtung der jeweiligen Nutzereinrichtung N1...NN 
dazu veranlasst, parallel zu der bestehenden HTTP -Verbindung 
zur Darstellung der aus den Feldgeraten FG1 . . . FGN geladenen 
HTML-Seite eine weitere Verbindung mit den Feldgeraten 
FG1...FGN aufzubauen. Diese zweite Verbindung benutzt das 
RPC-Protokoll, urn dynamische Daten, wie Ereignislisten oder 
Messwerte, aus den Feldgeraten FG1...FGN besonders schnell 
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und effektiv fur die Darstellung in den Nutzereinrichtungen 
N1...NN innerhalb einer angewahlten HTML-Seite, beispielswei- 
se der in Figur 3 gezeigten HTML-Seite 25, zu ubertragen. 

Inf ormationsabruf aus den Feldgeraten 

Figur 4 zeigt eine schematische Darstellung zur naheren Er- 
lauterung des Abrufens der Inf ormationen im Rahmen des BuB- 
Systems von den Feldgeraten FG1...FGN in die Nutzereinrich- 
tungen Nl . . . NN . 

GemaS Figur 4 ist auf einem Nutzer-Personalcomputer 30, der 
eine beispielhaf te Ausbildung der Nutzereinrichtungen Nl./.NN 
darstellt, eine Browser-Einrichtung 31 installiert • Der Nut- 
zer-Personalcomputer 30 ist liber ein IP-Netzwerk 32, welches 
den Proxyserver 1, den Sternkoppler 3, das Modem 4, das Modem 
5 sowie das Telekommunikationsnetzwerk 6 umfassen kann, mit 
einem Feldgerat 3 3 verbunden. Das Feldgerat 3 3 weist einen 
HTTP-Server 34 auf. In dem Feldgerat 33 sind HTML-Seiten 3 5 
gespeichert, die fur dieses Feldgerat 33 spezifische Inf orma- 
tionen umfassen. Die HTML-Seiten 35 enthalten beispielsweise 
eine HTML-Darstellung der Frontansicht des' Feldgerats' 33 . 
Die HTML-Seiten 35 sind speziell auf das Feldgerat 33 abge- 
stimmt und konnen mittels eines HTTP-Herunterladens vom HTTP- 
Server 34 des Feldgerats 33 durch den Nutzer-Personalcomputer 
30 abgerufen werden. Die Anforderung der HTML-Seiten 35 aus 
dem Feldgerat 33 kann mittels der Eingabe einer URL (URL - 
„ Uniform Resource Locator") in der Browser-Einrichtung 31 ci- 
der mittels der Referenz aus einer arideren HTML-Seite heraus 
(„Link") ausgelost werden. Neben den HTML-Seiten 35 werden 
vom Feldgerat 33 eine Reihe von Rohdaten 3 6 (Messwerte, Para- 
meter, etc.) in Form von Dateien bereitgestellt . In den 
HTML-Seiten 3 5 befinden sich Referenzen auf die im Feldgerat 
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33 verfiigbaren Rohdaten 36. Sollen die Rohdaten 36 ausgewer- 
tet oder in sonstiger Weise verandert werden, wird ein Pro- 
gramm benotigt, welches nach bestimmten Algorithmen hochwer- 
tige Datenf ormate erzeugen kann. Diese Datenf ormate konnen 
5 dann von dem Programm beispielsweise zur Bildschirmanzeige in 
Verbindung mit Analysemoglichkeiten verwendet werden . Die 
hierfur notwendige Rechenleistung steht in dem Feldgerat 3 3 
in der Regel nicht zur Verfugung. Mit Hilfe der Browser- 
Einrichtung 31 besteht fur den Anwender die Moglichkeit, un- 

10 ter Nutzung des IP-Netzwerks 32 iiber Kommunikationsverbindun- 
gen (Modem, Telef onnetze, LAN - „Local Area Network", WAN - 
„Wide Area Network") auf die HTML- Sei ten 3 5 aus dem Feldgerat 
33 und damit auch auf die hierin referenzierten Rohdaten 3 6 
des Feldgerats 3 3 zuzugreifen. Gemafi Figur 5 wird (werden) 

15 zu diesem Zweck mit Hilfe der Browser-Einrichtung 31 zunachst 
die HTML-Seite (n) 35 von dem Nutzer-Personalcomputer 30 ange- 
fordert. Nachdem der HTTP-Server 34 des Feldgerats 33 die 
HTML-Seite (n) 35, einschlieSlich der hierin enthaltenen Refe- 
renzen auf die Rohdaten 36, bereitgestellt hat, werden die 

20 HTML-Seite 35 und die Rohdaten 3 6 an den Nutzer-Personal- 
computer 30 ubertragen. Hierbei werden die HTML-Seite 35 und 
die Rohdaten 36 mittels getrennter Protokolle zwischen dem 
Feldgerat 33 und dem Nutzer-Personalcomputer 3 0 ubertiragen, 
vorzugsweise HTTP-bzw. RPC-Protokoll . In dem Nutzer- 

2 5 Personalcomputer 30 konnen die Rohdaten 3 6 dann mit geeigne- 

ten Programmen verarbeitet werden. Zum Ausfuhren des RPC- 
Protokolls umfasst das Feldgerat 33 zusatzlich einen RPC- 
Server 34a. 

3 0 Beim Herunterladen der HTML-Seite 3 5 vom HTTP-Server 3 4 kon- 

nen die referenzierten Dateien der Rohdaten 3 6 automat isch 
mit geladen werden. Der Aufruf aus der HTML-Seite 3 5 kann 
wie folgt aussehen: < EMBED SRC= ,, rawdata.ext">. Mit dem Para- 
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meter „SRC" wird die Datei mit den Rohdaten 3 6 des Feldgerats 
33 ref erenziert . Aufierdem kann das Herunterladen der Rohda- 
ten 3 6 auch liber einen vom Benutzer zu aktivierenden Link auf 
der HTML-Seite 35 ausgelost werden. Fur diesen Fall konnte 
5 der Aufruf in der HTML-Seite 3 5 wie folgt aussehen: 
<a href = n rawdata. ext " type= "mime type" >link</a> . 

Damit die Browser- Einrichtung 31 das richtige Programm zur 
Weiterverarbeitung der Rohdaten 3 6 starten kann, muss der 

10 Browser-Einrichtung 31 der Inhaltstyp der Rohdaten 3 6 mitge- 
teilt werden. Hierfur gibt es je nach verwendetem Betriebs- 
system des Nutzer-Personalcomputers 30 und genutzter Browser- 
Einrichtung 31 unterschiedliche Vorgehensweisen. Es kann so- 
wohl die Dateierweiterung (beispielsweise "*.ext") als auch 

15 der vom HTTP-Server 34 mitgelief erte MIME-Typ (MIME - Multi- 
purpose Internet Mail Extension") ausgewertet werden. Das 
von der Browser-Einrichtung 31 gestartete Programm zur Rohda- 
tenverarbeitung ubernimmt die Konvertierung der heruntergela- 
denen Rohdaten 36. Das Programm zur Rohdatenverarbeitung 

20 kann als Browser-Plugln, als ActiveX-Komponente oder als ex- 
ternes Programm realisiert werden. 

Hierbei ist zwischen verschiedenen Typen von Rohdaten zu un- 
terscheiden. Die Verarbeitung von sporadisch entstehenden 

25 Rohdaten 3 6 wird vorzugsweise mit Hilfe eines Browser- 
Plugln* s oder einer Active X-Komponente vorgenommen. In die- 
sem Zusammenhang erfolgt der Zugriff auf die Daten mit Hilfe 
des TCP-Protokolls . Sollen sich standig aktualisierende Roh- 
daten 3 6 in Form eines Endlos-Datenstroms verarbeitet werden, 

30 dann ist es sinnvoll, ein effektiveres Protokoll fur die U- 
bertragung an den Nutzer-Personalcomputer 30 (den Nutzerein- 
richtungen N1..NN) zu verwenden. Mit Hilfe des zusatzlichen 
RPC-Protokolls wird eine Auftrennung der in den Nutzerein- 
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richtungen N1...NN (bzw. dem Nutzer-Personalcomputer 30) dar- 
zustellenden Informationen uber das (die) Feldgerat(e) 
FG1. . . FGN bzw. 33 in statische und dynamische Informationen 
ermoglicht. Die statischen Informationen werden mit dem 
5 HTTP-Standardprotokoll ubertragen, wahrend die dynamischen, 
also veranderlichen Daten uber das effektivere RPC-Protokoll 
liber tragen werden. Der Aufwand, der beim Senden der dynami- 
schen Daten mittels des HTTP-Protokolls durch Verbindungsauf - 
bau/-abbau und Verbindungsuberwachung entstehen wurde , wiirde 

10 den des ereignisabhangigen, wiederholten Sendens der dynami- 
schen Daten mittels des RPC-Protokolls ubersteigen. Da in 
der Regel nur wenige Daten schnell ubex~mittelt werden sollen 
(Messwerte, Meldelisten, . ..), ist der Einsatz eines verbin- 
dungslosen Protokolls, insbesondere des RPC-Protokolls, fur 

15 die dynamischen Daten vorteilhaft. Bei einem Aufruf entfern- 
ter Prozeduren (RPC - „Remote Procedure Call") ruft ein loka- 
les Programm eine Prozedur auf einem entfernten System auf . 
Das Konzept des entfernten Prozedurauf ruf s sorgt dafiir, dass 
der gesamte Netzcode in der RPC-Schnittstelle und in den 

20 Netzroutinen verborgen bleibt. Damit wird vermieden, dass 
sich die Applikationsprogramme (Client und Server) um De- 
tails, wie z.B. Konvertierung EBCDIC < > ASCII, Zahlenkon- 

vertierung, Socket, Session etc., kummern miissen. Ein Ziel 
von RPC ist die Vereinf achung der Implement ierung von ver- 

25 teilten Anwendungen. UDP (UDP - „User Defined Protocol' 7 ) wird 
von einigen Anwendungen, die nur kurze Nachrichten senden und 
diese wiederholen konnen, verwendet . UDP ist daher ein idea- 
les Protokoll zur Verteilung von Informationen, die sich 
standig andern, wie beispielsweise Borsenkurse. Statt die Da- 

3 0 ten in ein TCP-Umschlag zu packen und dann in den IP- 

Umschlag, wandern sie jetzt in einen UDP-Umschlag, bevor sie 
in den IP-Umschlag kommen. Obwohl UDP in der gleichen Schicht 
wie das verbindungsorientierte TCP beheimatet ist, handelt es 
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sich urn ein verbindungsloses Protokoll. Der Einsatz des UDP 
Protokolls erscheint immer dann sinnvoll, wenn nur wenige Da- 
ten schnell iibermittelt werden sollen. So gibt es in Anwen- 
dungsprogrammen zwischen Client und Server einen Austausch 
5 von kurzen Anfragen und Antworten . Hier wiirde der Aufwand der 
durch Verbindungsauf bau/ -abbau und Verbindungsuberwachung 
entsteht, den des erneuten Sendens der Daten ubersteigen. Das 
getrennte Ubertragen von statischen und dynamischen Daten 
zwischen den Feldgeraten FG1 . . . FGN im Geratenetzwerk und den 
10 Nutzereinrichtungen N1...NN im Firmen- Intranet mit Hilfe un- 
terschiedlicher Protokolle wird durch das Vorsehen und die 
spezifische Ausbildung des spater im Detail beschriebenen 
Proxyservers 1 optimiert . 

15 Im folgenden wird die Nutzung des RPC-Protokolls zum Abrufen 
der dynamischen Daten in einer Client / Server -Anordnung (Nut- 
zereinrichtungen Nl. . .NN/Feldgerate FG1 . . . FGN) anhand der 
schematischen Darstellung in Figur 6 beschrieben. 

20 Ein RPC-Aufruf lauft beispielsweise wie folgt ab: 

(a) Ein innerhalb des Brwosers 31 (vgl . Figur 4) ablaufender 
Clielnt-Prozess 100 ruft eine RPC-Schnittstelle 101'auf. 
Dieser Client-Prozess 100 kann z.B. ein in eine HTML- 
Seite eingebettetes Java-Applet sein. Die RPC- 

25 Schnittstelle 101 hat die Aufgabe, den Unterprogrammein- 

sprung zu spezif izieren . Die Spezif ikation enthalt den 
Namen der Funktion sowie Anzahl und Typen der Parameter. 
Hiermit wird ein logischer Einsprung def iniert . Die RPC- 
Schnittstelle 101 ermoglicht das Starten der entfernt 

30 liegenden Prozedur 102. 

(b) Die Parameter des Client-Prozesses 100 werden von der 
RPC-Schnittstelle 101 gelesen. Der Zweck der RPC- 
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Schnittstelle 101 liegt in der Verpackung und Konvertie- 
rung der Parameter fur das Serverprogramm. 
(c) Die Netzroutinen versenden die Nachrichten an einen Ser- 
ver-Prozess 103, der im RPC- Server 34a ablauft. 
5 (d) Eine RPC-Schnittstelle 104 des Server-Prozess 103 baut 
die Parameter aus den Nachrichtenpaketen wieder auf . 

(e) Im nachsten Schritt wird das Serverprogramm aufgerufen. 
Dazu wird ein Serverstub definiert. Dieser Stub ist der 
eigentliche Einsprung in die auf dem Server-Prozess 103 

10 liegende Prozedur. 

(f ) Nach Abarbeitung der Prozedur wird die Kontrolle wieder 
an die RPC-Schnittstelle 104 gegeben. 

(g) Die Schnittstelle 104 verpackt die Riickgabeparameter und 
transportiert die Daten anschlieSend zu den Netzroutinen, 

15 (h) Die Netzroutinen transportieren die Daten liber netzwerk- 
abhangige Aufrufe auf den Client-Prozess 100. 
(i) Die RPC-Schnittstelle 101 des Client-Prozesses 100 ent- 
packt die Parameter und versorgt die angegebenen Parame- 
ter mit den neuen Daten. 

20 (j) Die Kontrolle wird an den Client-Prozess 100 zuruckgege- 
ben, der die erhaltenen Daten weiterverarbeiten kann. 



Das Konzept des entfernten Prozedurauf ruf s sorgt dafur, dass 
der gesamte Netzcode in der RPC-Schnittstelle und in den 

25 Netzroutinen verborgen bleibt. Damit wird vermieden, dass 
sich die Applikationsprogramme (Client und Server) urn De- 
tails, wie z.B. Konvertierung EBCDIC < > ASCII , Zahlenkon- 

vertierung, Socket, Session etc., kummern mussen. Ein Vor- 
teil der Nutzung des RPC-Protokolls fur die dynamischen Daten 

3 0 ist die Vereinf achung der Imp lementie rung von verteilten An- 
wendungen . 
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Bedienen der Feldgerate 

Der in Verbindung mit Figur 4 beschriebene Abruf von Informa- 
tion von dem Feldgerat 33, welches den HTTP-Server 34 um- 
5 fasst, kann auch in Verbindung mit Handlungen im Rahmen des 
Beobachtungs- und Bediensystem genutzt werden, die zum Zweck 
des Bedienens des Feldgerat s 3 3 ausgefiihrt werden. Hierdurch 
ist es ermoglicht, das Feldgerat 33 mit Hilfe der Browser- 
Einrichtung 31 zu bedienen. Dieses wird im folgenden naher 
1 0 beschrieben . 

Das Feldgerat 33 enthalt eine Speichereinrichtung 35a , in 
welcher Bediensof tware in Form von HTML -Sei ten 35 gespeichert 
ist, und ein Java-Archiv oder Daten, aus denen HTML-Seiten 

15 erzeugbar sind. Die Bediensof tware ist speziell auf das 
Feldgerat 33 zugeschnitten . ' Mittels der Eingabe der URL- 
Adresse des Feldger&ts 3 3 durch den Nutzer startet ein HTTP- 
Herunterladen, was zum Herunterladen der Bediensof tware vom 
HTTP-Server 34 des Feldgerats 33 in den Nutzer-Personal - 

2 0 computer 3 0 fuhrt. Nach dem Herunterladen der Bediensof tware 
von dem Feldgerat 33 auf den Benutzer-Personalcomputer 30 in 
Form der HTML-Seite (n) 35 wird die Vorderansicht des Feldge- 
rats 33 mit alien Bedien- und Anzeige-Elementen innerbalb der 
Browser-Einrichtung dargestellt (vgl . Figur 3). Der Benutzer 

2 5 kann dann bestimmte Bedienf unktionen des Feldgerats 3 3 mit 

Hilfe eines Mausklicks auf dem Bildschirm des Benutzer- 
Personalcomputers 3 0 auslosen. Die Ubermittlung der Benut- 
zerhandl\ing zum Feldgerat 33 erfolgt mittels eines schnellen 
und effektiven Protokolls, das einerseits die genannten Be- 

3 0 dienanforderungen vom Benutzer-Personalcomputer 3 0 zum Feld- 

gerat 33 ubertragt und andererseits Reaktionen des Feldgerats 
33 zuruckliest. Zu diesem Zweck werden die internen Bedien- 
und Anzeigefunktionen des Feldgerats 33 sur Schnittstelle der 
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Browser-Einrichtung 31 hin verof f entlicht , z.B. Tastaturpuf- 
fer, Displaypuf f er, LED-Status. 

Im Rahmen der Bedienung durch den Benutzer gibt es zwischen 
5 Benutzer-Personalcomputer 3 0 und dem Feldgerat 33 einen Aus- 
tausch von kurzen Anfragen und Antworten im Rahmen einer 
Client-Server-Verhaltnisses . Hierbei wurde der Aufwand, der 
im Zusammenhang mit dem Aufbau/Abbau und der Uberwachung der 
HTTP-Verbindung zwischen dem Benutzer- Per sonalcomputer 3 0 und 

10 dem Feldgerat 3 3 entsteht, den Aufwand ubersteigen, der beim 
erneuten Senden und Empfangen der Daten gemaS eines verbin- 
dungslosen Protokolls entsteht. Da in der Regel nur wenige 
Daten schnell ubermittelt werden sollen (z.B. Tastendruck, 
Displayinhalt, LED-Status), ist der Einsatz eines schnellen, 

15 effektiven, verbindungslosen Protokolls sinnvoll, beispiels- 
weise des oben beschriebenen RPC- Protokolls . Zur Reduktion 
der ausgetauschten Datenmenge (z.B. Displayinhalt) zwischen 
dem Benutzer— Personalcomputer 30 und dem Feldgerat 33 werden 
Verfahren zur Komprimierung von Daten eingesetzt. 

20 

Internet-Protokolle, wie TCP/IP und HTTP, bieten keinerlei 
Sicherheitsmechanismen. Es sind zusatzliche Protokolle not- 
wendig, urn eine sichere Kommunikation zu ermoglichen. Die Me- 
chanismen zum Schutz sicherheitsrelevanter Aktionen am Feld- 
25 gerat 33 iiber TCP/ IP- Kommunikation sind von besonderer Bedeu- 
tung. Hinsichtlich des Schutzes gegen unbefugte Zugriffe 
lassen sich die Bedienhandlungen am Feldgerat 33 klassifizie- 
ren (vgl . Tabelle 1) . 

3 0 Tabelle 1 



Aktion 


Sicherheits-Risiko 


MaSnahmen 


Messwerte le- 
sen; 


Gering - beim Mitlesen des 
RPC-Datenverkehrs konnen 


Es wird ein internes 
UDP-Protokoll (UDP - 
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Aktion 


Sicherheits-Risiko 


Mafenahmen 


Mel dungs listen 
lesen 


Informationen zur Be- 
triebsfuhrung (Betriebs- 
messwerte, Meldungen, 
Storfalle) lm Umfang der 
auf den HTML-Seiten ange- 
zeigten Daten eingesehen 
werden 


„User Defined Proto- 
col " ) verwendet . Da 
dieses Protokoll nur 
dem Hersteller be- 
kannt ist, ist fur 
das Entschlusseln 
der Inhalte ein Re- 
Engineering notwen- 
dig 


Gerat umpara - 
metrieren 


Hoch - diese Aktionen sind 
am Gerat passwortgesichert 


Optionale Verschlus- 
selung der sehr kur- 
zen Protokolle (auf- 
wandig) 


Schalten, Steu- 
em, Puffer 16- 
schen 


Sehr hoch - die Protokolle 
konnen aufgezeich.net und 
spater wiederholt werden 


12 8-Bit-Verschlus- 
selung passwortgesi- 
cherter Aktionen 



Missbrauchliche Handlungen beim Bedienen des Feldgerats 33 
konnen mittels der folgenden MaSnahmen im wesentlichen ausge- 
5 schlossen werden: 

Mit Hilfe einer Firewall (z.B. Proxyserver) kann das interne 
Netz (Firmen-Intranet/LAN) eine geschiitzte Verbindung mit ei- 
nem anderen Netz (z.B. Internet) aufnehmen. 

10 

Das Feldgerat 33 ist im Lief erzustand so eingestellt , dass 
Tasten, die die vollstandige Eingabe von Kundenpasswortern er- 
moglichen, gesperrt sind. Diese Sperre muss vom Kunden am 
Feldgerat 33 selbst bzw. mit dem Bedienprogramm in der Brow- 
15 ser-Einrichtung 31 auf dem Nut zer-Personalcomputer 30 aufgeho- 

ben werden (Passworteingabe erf orderlich) . Im Lief erzustand 
sind damit nur einfache Bedienhandlungen viber die Browser- 
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Einrichtung 31 moglich: Navigation im Bedienmenu, Anzeige von 
Messwerten, Parametern und Meldungslisten. 

Die Parametrierung des Feldgerats 33 in der Frontansicht- 
5 Emulation ist mit Kenntnis der Passworter wie am Feldge- 

rat 33 moglich, wenn die Sperrung der dazu bendtigten 
Tasten gelost ist, 

Sicherheitsrelevante Aktionen am Feldgerat 3 3 (Schalten, 
Steuern, Loschen von Puffern, . werden durch Authenti- 
f ikationsprotokolle geschutzt, z,B. mittels Hash-Funktion 
und eines vom Feldgerat 33 generierten Schliissels. Damit 
konnen aus dem Verbindungsprotokoll keine Riickschlusse 
auf eingegebene Passworter erfolgen. Mit diesem Verfah- 
ren wird aus einer beliebig langen Nachricht eine 12 8 Bit 
lange Information, der sogenannte ^Message Digest w , ge- 
bildet, der an die originare Nachricht angehangen wird. 
Der Empf anger (Feldgerat 33) vergleicht den ^Message Di- 
gest" mit dem vom Feldgerat 33 aus der Information ermit- 
telten. Dadurch werden Feldgeratepassworter nicht uber 
die Kommunikationsverbindung ubertragen. 

Die im Feldgerat 33 generierten Schliissel verfallen nach 
kurzer Zeit und konnen nur einmal fur eine Ubertragung 
25 verwendet werden. Damit ist die Aufzeichnung von sicher- 

heitsrelevanten Protokollen und eine spatere Wiederholung 
dieser auf gezeichneten Protokolle wirkungslos. 

3 0 Proxyserver 

Ein Element zur optimierten Umsetzung des beschriebenen funk- 
tionellen Zusammenwirkens der Elemente des Beobachtungs- und 
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Bediensystems, beispielsweise der Nutzung des RPC-Protokolls , 
des Abrufs der Rohdaten aus den Feldgeraten FG1 . . . FGN und der 
Bedienung der Feldgerate mittels Browser auf den Nutzerein- 
richtungen N1...NN, ist der Proxyserver 1. Bekannte Stan- 
5 dard-HTTP- Proxyserver unterstiitzen ausschlieSlich das HTTP- 
Protokoll und sind somit nicht in der Lage, als Gateway zwi- 
schen dem Geratenetzwerk und dem Firmen- Intranet zu dienen. 
Aus diesem Grund wurde ein spezif ischer , fur das BuB-System 
konzipierter Proxyserver 1 geschaffen, der beide von den 
10 Feldgeraten FG1...FGN verwendeten Protokolle (HTTP, RPC) un- 
terstiitzt . 

Ein wesentlicher Vorteil, der bei der Nutzung des Proxyser- 
vers 1 gegeniiber der Ankopplung des Geratenetzwerks an das 
15 Firmen- Intx~anet mittels Routers oder, wenn keine WAN- 

Verbindung (WAN - „Wide Area Network") zwischen dem Gerate- 
netzwerk und dem Intranet besteht, einer direkten Ankopplung 
des Gerate-Netzsegments uber einen Hub Oder einen Switch be- 
steht in der Nutzung des sogenannten ^Cachings w • 

20 

Das diesem Verfahren ( /; Caching u ) zugrunde liegende Prinzip 
wird im folgenden allgemein, ohne Bezugnahme auf die oben ge- 
nannten Figuren, kurz beschrieben. 

25 Stellt ein Client eine Anfrage nach einem Objekt an eine Ser- 
vereinrichtung, so lauft diese Anfrage zunachst uber eine so- 
genannte Proxy-Einrichtung . Die Proxy-Einrichtung schaut 
nach, ob sich das betreffende Objekt bereits in einem lokalen 
Speicher (Cache) der Proxy-Einrichtung befindet, welcher in 

30 der Regel auf einer Festplatte ausgebildet ist. Wird hierbei 
festgestellt, dass das Objekt nicht lokal im Speicher vor- 
liegt, reicht die Proxy-Einrichtung die Anfrage weiter zu ei- 
ner eigentlichen Zielserver-Einrichtung . Von dort erhalt die 
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Proxy-Einrichtung das Objekt und speichert eine Kopie des Ob- 
jekts fur weitere Anfragen nach diesem Objekt in dem lokalen 
Speicher, bevor die Proxy-Einrichtung das Objekt an den an- 
fragenden Client weitergibt . Wird das Objekt jedoch im loka- 
len Speicher der Proxy-Einrichtung gefunden, so wird die An- 
frage des Clients nicht an die Zielserver-Einrichtung durch- 
gestellt, sondern der Client bekommt das gewunschte Objekt 
direkt von der Proxy-Einrichtung ubermittelt. Voraussetzung 
fur optimales Ausfiihren des beschriebenen Verfahrens ist ein 
genugend grofier Speicher-Bereich in der Proxy-Einrichtung, 
d.h. in der Grofienordnung von mehreren Hundert MB bis mehre- 
ren GByte. Ansonsten lauft der lokale Speicher in der Proxy- 
Einrichtung uber und es muss ein „Garbage Collector" (ein so- 
genannter Auf raumdienst ) gestartet werden, der veraltete Ob- 
jekte aus dem Speicher heraus filtert, um dort Platz fur neue 
Objekte zu schaffen. 

Vorteile des beschriebenen Verfahrens („ Caching") sind: eine 
Verbesserung der Leistungsf ahigkeit (schnellerer Datentrans- 
port als extern) ; eine Einsparung von externer Bandbreite 
(mehr Platz fur andere Dienste bleibt frei) ; eine Verminde- 
rung der Antwortzeiten 

Entlastung der Zielserver-Einrichtung; beim Transport des Ob- 
jekts von der Proxy-Einrichtung zum Client entstehen keine 
bzw. geringere Ubertragungskosten; und die Tref f erquoten im 
lokalen Speicher der Proxy-Einrichtung konnen je nach Nutzung 
sehr hoch sein. 

Der zum Verbinden des Geratenetzwerks und des Firmen- 
Intranets (vgl. Figur 1) genutzte Proxyserver 1 basiert auf 
dem beschriebenen Grundprinzip und hat aufgrund der spezifi- 
schen Ausbildung, welche im Detail spater beschrieben wird, 
daruber hinaus die im folgenden genannten Vorteile. 



03036400A1_I_> 



WO 03/036400 



PCT/DE02/03849 



23 

Durch den Einsatz des Proxyservers 1 (vgl . Figur 1) ergeben 
sich deutliche Geschwindigkeitsvorteile beim Zugriff auf das 
Geratenetzwerk. Der Proxyserver 1 umfasst einen fur die An- 
5 wendung im BuB-System optimierten Dateispeicher bzw. Dateica- 
che, der alle aus den Feldgeraten FG1...FGN abgerufenen Da- 
teien mit statischen Daten im Proxyserver 1 puffert. Wird 
auf eine solche Datei das erste Mai zugegriffen, dann muss 
diese Datei direkt aus einem der Feldgerate FG1...FGN geholt 

10 werden. Bei einem wiederholten Zugriff auf diese Datei kann 
diese dann jedoch direkt aus dem Dateicache des Proxyservers 
1 geliefert werden. Da das lokale Firmen- Intranet im allge- 
meinen viel schneller als eine Modemverbindung zu den Feldge- 
raten FG1...FGN ist, ergeben sich hier signifikante Geschwin- 

15 digkeitsvorteile beim Zugriff auf das Geratenetzwerk, da im 
laufenden Betrieb nur noch die gegemiber den HTML-Seiten und 
den Java-Archiven deutlich kleineren dynamischen Daten uber 
die langsame Modemverbindung ubertragen werden. 

2 0 Der Proxyserver 1 erhoht dariiber hinaus die Sicherheit im 

Netzwerk. Der Proxyserver 1 schottet die beiden Netzwerke, 
Geratenetzwerk und Firmen- Intranet , gegeneinander. ab und .u- 
bertragt nur die im Proxyserver 1 verarbeiteten Protokolle. 
Dies bedeutet, dass aus dem Firmen- Intranet nur die von einem 
25 Browser auf den Nutzereinrichtungen Nl . . .NN an die. Feldgerate 
FG1. . . FGN generierten Anf orderungen ubertragen werden. In 
die Gegenrichtung werden nur die von den Feldgeraten 
FG1...FGN generierten Antworten ubertragen. Damit werden al- 
le anderen im Firmen- Intranet kursierenden Datenpakete vom 

3 0 Geratenetzwerk ferngehalten und beeinflussen somit nicht den 

Durchsatz im Geratenetzwerk. Des weiteren kann ein im Gera- 
tenetzwerk auf tretendes, hohes Datenauf kommen aufgrund von 
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Querkommunikation zwischen den Feldgeraten FG1...FGN die 
Netzlast itn Firmen- Intranet nicht erhohen. 

Die Nutzung des RPC-Protokolls mittels des Proxyservers 1 
5 hat den Vorteil, dass sichergestellt ist, dass die Zugriffs- 
moglichkeit auf die Feldgerate FG1...FGN auf das an den Pro- 
xyserver 1 angeschlossene Firmen- Intranet beschrankt bleibt. 
Ein Firmen- Intranet ist heute ublicherweise uber ein HTTP- 
Gateway rait dem Internet verbunden. Dieses Gateway ubernimmt 

10 hier eine Firewall-Funktion (vgl . Figur 7), indent es die U- 

bertragung des RPC-Protokolls blockiert. Hierdurch kann au- 
Serhalb des Firmen- Intranets nicht mehr auf die Daten der 
Feldgerate FG1...FGN zugegriffen werden, da alle dynamischen 
Daten der Feldgerate FG1. . .FGN uber das RPC-Protokoll uber- 

15 tragen werden. 

Der Proxyserver 1 ermoglicht vielfaltige Funktionen, die bei 
dem bisher ublichen, direkten Zugang zu den Feldgeraten 
FG1...FGN nicht zur Verfugung stehen. Die folgende Zusammen- 

2 0 stellung listet weitere wesentliche Funktionen auf, die sich 

in Verbindung mit der nachf olgenden, detaillierten Beschrei- 
bung des Proxyservers 1 ergeben: 

- Es wird eine eigene Homepage zur Verfugung gestellt, liber 
die alle angeschlossenen Feldgerate FG1...FGN erreichbar 

25 sind. 

- Die angeschlossenen Feldgerate FG1 . . . FGN werden automa- 
tisch adressiert und erkannt; Darstellung dieser Feldgera- 
te FG1...FGN in der Homepage als Startseite auf den Nut- 
zereinrichtungen N1...NN fur einen direkten Geratesugrif f . 

3 0 Es wird der Zugriff uber Geratenamen der Feldgerate 

FG1. . . FGN ermoglicht, dies ist gegenuber dem Zugriff uber 
die IP-Adresse nutzerf reundlicher . 
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Der Proxyserver 1 kann mittels Browser auf den Nutzerein- 
richtungen N1...NN konfiguriert werden (e-mail -Adressen, 
Telefon-Nummern, Geratenamen, . . . ) 

Der Proxyserver 1 definiert die moglichen Zugriffswege 
5 („Firewall-Funktion") . 

Der Proxyserver 1 kann Daten aus den Feldgerate FG1 . . . FGN 
zwischenspeichern. Diese Funktion eignet sich z. B. fur 
die Protokollierung der Storf allinf ormationen oder der Be- 
triebsmesswerte. Diese Daten werden intern in einer XML- 

10 Datenbank (XML - ^Extended Markup Language") abgelegt. 

Der Proxyserver kann die aus den Feldgeraten FG1 . . . FGN li- 
ber das RPC-Protokoll ubertragenen Daten im XML -Format zur 
Verfugung stellen. Hierdurch konnen beispielsweise nut- 
zerspezif ische Erweiterungen der im Proxyserver 1 verfug- 

15 baren Darstellungen vorgenommen werden. Hierzu steht ein 

im Proxyserver 1 integrierter XSL- Parser (XSL - „ Extended 
Stylesheet Language") zur Verfugung. 

Durch die mit Hilfe des XSL-Parsers realisierbaren Filter 
auf die XML-Datenbank kann der Proxyserver 1 ebenfalls als 

2 0 Client fur weitere Applikationen genutzt werden. 

Signal isierung von Ereignissen im LAN (LAN - „ Local Area 
Network") via e-mail ist moglich. Der Proxyserver 1- stellt 
eigene e-mail-Postf acher zu Verfugung, die mittels eines 
POP3 -Clients (POP3 - „Post Office Protocol Stepping 3") , 

25 wie z.B. Outlook, abgerufen werden konnen. Weiterhin ist 

eine Weiterleitung von e-mails an ein anderes Postfach 
mittels eines im Proxyserver 1 integrierten SMTP-Servers 
(STMP - „ Simple Message Transfer Protocol w ) moglich. 

30 Im folgenden wird die Ausbildung des Proxy servers 1 naher be- 
schreiben . 
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Figur 7 zeigt eine Anordnung mit dem Geratenet zwerk und dem 
Pirmen- Intranet gemafi Figur 1, wobei Elemente des Proxyser- 
vers 1 schematisch gezeigt sind. Figur 8 zeigt Funktionsblo- 
cke des Proxyservers 1 in einem Blockschaltbild . 

GemaS Figur 7 weist jedes der Feldgerate FG1 . . . FGN einen je- 
weiligen HTTP-Server HS1...HSN auf, die dem jeweiligen HTTP- 
Server 34 (vgl. Figur 4) entsprechen und mit einem Sternkopp- 
ler 3 9 verbunden sind. Der Proxyserver 1 verfiigt ebenfalls 
uber einen HTTP-Server 40. Im folgenden wird die Arbeitswei- 
se des Proxyservers 1 unter Bezugnahme auf Figur 8 beschrie- 
ben . 

Der Zugrif f auf den Proxyserver 1 geschieht immer aus dem lo- 
kalen Netz des Firmen- Intranets heraus, in dem sich die Nut- 
zereinrichtungen N1...NN mit der jeweiligen Modemverbindung 
in das die Feldgerate umfassende Geratenet zwerk befinden, das 
ein Umspannwerk oder mehreren Unterwerken umfassen kann. Wird 
eine der Nut zereinrichtungen N1...NN liber die zugehorige lo- 
kale IP-Adresse als Server angesprochen, wird dieser Zugriff 
uber einen TCP/IP-Stack 41 (TCP - ^Transfer Control Proto- 
col w ) an den HTTP-Server 40 weitergeleitet . 

Der HTTP-Server 40 liefert die angef orderten Dateien in das 
Firmen- Intranet . Zu diesem Zweck wendet sich der HTTP-Server 
40 uber einen Dateifilter 42 an eine Cacheverwaltung 43. Der 
Dateifilter 42 leitet die Anforderung normalerweise an die 
Cacheverwaltung 43 weiter. Nur bestimmte Anf orderungen wer- 
den anhand des angef orderten Dateityps erkannt und einem an- 
deren Verar*beitungsweg zugefuhrt. Diese Ausnahmen werden 
spater beschrieben. Die Cacheverwaltung 43 versucht als ers- 
tes, die angef orderte Datei in den lokalen Dateien 44 oder in 
einem Dateicache 45 zu finden. 1st die angeforderte Datei 
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weder eine lokale Datei des Proxyservers 1 noch im Dateicache 
4 5 vorhanden, wird die Dateianf orderung an einen HTTP- Client 
46 weitergeleitet . Dieser baut liber einen weiteren TCP/IP- 
Stack 47 eine Verbindung zum HTTP-Server HS1, ... bzw. HSN 
5 des angesprochenen Feldgerats FG1, ... bzw. FGN im Gerate- 

netzwerk auf, um die angeforderte Datei von dort zu beziehen. 

Als Verbindung zum Geratenetzwerk wird vorzugsweise eine Mo- 
demverbindung mit dem PPP-Protokoll genutzt (vgl . Figur 1) . 

10 Da der Proxyserver 1 uber diese Modemverbindung jedoch 

gleichzeitig mehrere Verbindungen zu verschiedenen Feldgera- 
ten FG1...FGN halten kann, ist eine Arbitierung dieser Modem- 
verbindung erforderlich, da das PPP-Protokoll nur eine Punkt- 
zu Punkt -Verbindung verwalten kann. Hierzu dient ein Block 

15 Slot-Protokoll 48. Dieses Protokoll teilt den einzelnen PPP- 
Verbindungen Zeitscheiben auf der Modem-Kommunikationsstrecke 
zu und verhindert so Kollisionen zwischen den einzelnen Ver- 
bindungen. Der Block Slot-Protokoll 48 ist weiterhin dafur 
zustandig, alle im Geratenetzwerk aktiven Feldgerate 

20 FG1...FGN zu erkennen. Dazu wird das Geratenetzwerk zyklisch 
nach aktiven Feldgeraten abgesucht . Die erkannten aktiven 
Feldgerate werden von einer Gerateverwaltung 49 in- eine XML - 
Datenbank 50 des Proxyservers 1 eingetragen. 

2 5 Bei der XML -Datenbank 50 handelt es sich um einen nach dem 

standardisierten „ Document Object Model u abgelegten Daten- 
baum. Enthalt nun eine uber den HTTP- Server 4 0 in den Brow- 
ser einer mit dem Proxyserver 1 verbunden Nut zungseinrichtung 
Nl # ... bzw. NN geladene HTML-Seite Java-Code, der eine pa- 

3 0 rallele UDP- Verbindung (UDP - „User Defined Protocol u ) fur 

das RPC- Protokoll auf baut, dann wird uber diesen Weg ein 
RPC- Server 51 aus dem Firmen- Intranet heraus angesprochen. 
Da das RPC-Protokoll aus Leistungsgriinden auf das standardi- 
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sierte UDP/lP-Protokoll aufsetzt, muss hier im Proxyserver 1 
eine Verbindungsverwaltung 52 enthalten sein, da das UDP- 
Protokoll nicht verbindungsorientiert arbeitet . Die Verbin- 
dungsverwaltung 52 stellt sicher, dass fur jede Nutzungsein- 
5 richtung N1...NN aus dem Firmen- Intranet ein eigener Kommuni- 
kationsport fur einen RPC-Client 53 des Proxyservers 1 in das 
Geratenetzwerk reserviert wird. Die RPC-Anf orderungen aus 
dem Firmen- Intranet werden dann liber den RPC-Client 53 des 
Proxyservers 1 direkt in das Geratenetzwerk weitergeleitet . 

10 

Die Antworten der Feldgerate FG1...FGN auf RPC-Anf orderungen 
werden an den RPC- Server 51 weitergeleitet. Dieser gibt die 
Antwort des jeweiligen Feldgerats FG1 , ... bzw. FGN an die 
Nutzereinrichtungen liber, das Firmen- Intranet weiter. Paral- 
15 lei hierzu werden die aktuell im RPC-Protokoll ubertragenen 
dynamischen Daten aus dem jeweiligen Feldgerat FG1, . . - bzw. 
FGN in der XML-Datenbank 50 im Proxyserver 1 abgelegt . 

Die in der XML-Datenbank 50 gespeicherten Daten konnen mit 
20 Hilfe eines im Proxyserver 1 integrierten XSL-Parsers 54 in 
beliebige andere Datenformate konvertiert werden. Die dazu 
notwendigen Transf ormationsanweisungen mussen als XSL- 
Scriptdatei lokal im Proxyserver 1 abgelegt werden. Urn einen 
solchen Transf ormationsprozess auszulosen, muss am HTTP- 
25 Server 40 eine *.XML-Datei angefordert werden. Eine solche 
Anforderung wird von dem am HTTP-Server 4 0 angeschlossenen 
Dateifilter 42 aus dem normalen Zugriffsweg auf die Cachever- 
waltung 43 herausgef iltert und an den XSL-Parser 54 weiterge- 
leitet. Dieser liest aus den im Proxyserver 1 lokal abgeleg- 
30 ten Dateien neben der angefordert en XML-Datei eine gleichna- 
mige XSL-Datei und startet den Transf ormationsprozess . Das 
Ergebnis dieser Transformation wird vom HTTP-Server 4 0 an den 
anfordernden Nutzer gesendet. Auf diese Weise konnen z. B. 
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HTML-Dateien dynamisch aus einer XSL-Vorlage mit den aktuel- 
len Daten der Feldgerate FG1 . . . FGN aus der XML-Datenbank 50 
erzeugt oder einfach ein Teilbaum der Datenbank als XML-Datei 
libertragen werden. 

5 

Der Dateifilter 42, die Cache -Verwaltung 43, die lokalen Da- 
teien 44, der Dateicache 45, der XSL-Parser 54 sowie die XML- 
Datenbank 50 bilden ein Dateisystem des Proxyservers 1. 

10 Im folgenden werden einzelne Funktionsblocke des Proxyservers 
1 naher beschrieben . 

HTTP- Server 

15 Zunachst wird die grundsatzliche Arbeitsweise des im Proxy- 
server 1 ausgebildeten HTTP-Servers 40 (vgl . Figur 8) erlau- 
tert, wobei zum besseren Verstandnis einige wesentliche 
Gx~undlagen des HTTP's beschrieben werden. 

20 Wie bei anderen Applikationsprotokollen im Internet handelt 
es sich bei HTTP (HTTP - „Hypertext Transfer Protocol") urn 
ein ASCII -Protokoll , das fur den Datenaustausch eine abgesi- 
cherte TCP-Verbindung zwischen einem Client (Computer des In- 
ternetnutzers) und einem Server (Servereinrichtung, auf wel- 

25 cher abrufbare Internetinhalte - Daten - zur Verfugung ste- 
hen) benotigt. Als Ankniipf ung spunk t ist dabei der Port 80 
definiert, d. h. , ein HTTP-Server lauscht an diesem Port auf 
neue Client -Verbindungen. Alternativ kann die uberwiegende 
Anzahl von HTTP -Server- Software uber einen entsprechenden 

3 0 Konf igurationsdialog auch angewiesen werden, einen anderen 
Port fur die Kontaktauf nahme heranzuziehen . 
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Anders als bei anderen Protokollen, z. B. FTP (FTP - „File 
Transfer Protocol*) und P0P3 , ist eine Verbindung zwischen 
einem HTTP-Client und einem HTTP-Server sehr kurzlebig. Der 
HTTP-Client baut eine TCP-Verbindung zum gewunschten HTTP- 
5 Server liber den Port 80 auf und setzt eine Anfrage nach einem 
gewunschten Dokument an den HTTP-Server ab. Der HTTP-Server 
erhalt die Anfrage, wertet sie aus und sendet - im Erfolgs- 
fall - das gewunschte Dokument an den HTTP-Client zuruck. 
Der HTTP-Server schlieEt die TCP-Verbindung automatisch, 
10 nachdem er dem HTTP-Client das geforderte Dokument oder eine 
Fehlermeldung als Antwort auf dessen Anfrage zugesandt hat. 

Eine wichtige Funktionalitat von HTTP ist es, dass der HTTP- 
Client dem HTTP-Server mitteilen kann, welche Art von Daten 
dieser verstehen kann. Es muss also bei jeder Anfrage eine 
Kommunikation zwischen dem HTTP-Client und dem HTTP-Server 
dariiber stattfinden, wie die Daten ubertragen werden sollen. 
Diese Kommunikation erzeugt einen sogenannten Uberschuss bzw. 
Uberhang („overhead" ) ; HTTP wird deshalb auch als statusloses 
Protokoll („ stateless protocol") bezeichnet, weil die Verbin- 
dung nicht mehrere Phasen durchlauft, vom Einloggen, liber den 
Datenaustausch bis hin zum Ausloggen durch den HTTP-Client. 
Dieses erleichtert einerseits die Entwicklung von HTTP- 
Client-/HTTP-Server-Software, ist aber im Hinblick auf die 
Nutzung der zur Verfugung stehenden Bandbreite nicht sehr ef- 
fizient. 

Das HTTP- Protokoll wird verwendet, urn Zugriff auf Quellen im 
URL-Format (URL - „ Uniform Resource Locator u ) zu erlangen. 
3 0 Der HTTP-Client, meistens ein Web-Browser auf dem Computer 

des Internet -Benutzers. Er verlangt eine HTML-Seite und gene- 
riert danach eine Sequenz von Anfragen bezuglich der Datei- 
verweise in dieser HTML-Seite. Danach wird der Benutzter 
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wahrscheinlich einen Link in der angefragten HTML-Seite an- 
klicken, und der HTTP-Client schickt eine Anfrage, beziiglich 
der mit diesem Link verkmipften HTML-Seiten, an den gleichen 
oder einen weiteren HTTP-Server. Diese weiteren Kommunikati- 
5 onsverbindungen haben keine Informationen mehr uber eine vor- 
hergegangene Verbindung. Dieses funktioniert bei einfachen 
Client/Server-Umgebungen. Bei umf angreicheren Kommunikatio- 
nen. kann diese Arbeitsweise allerdings zutn Problem werden, 
denn fur jede noch so kleine Datenmenge, die iibertragen wer- 
10 den soli, fallt dieser Uberschuss („ Overhead » ) an, was die 
Effizienz mindert . 

Figur 9 zeigt eine schematische Darstellung der Syntax einer 
Anfrage in Verbindung mit einer HTTP-Client/Server- 
15 Interaktion. 

Die HTTP-Client/Server- Interaktion besteht aus einer einzigen 
Anf rage /Ant wort- Kommunikat ion. Sie umfasst eine „ request li- 
ne", ein oder mehrere optionale ^request header fields " und 

20 einen optionalen „entity body". Von der HTTP-Client-Seite 
60, also in der Regel vom Internet -Browser aus, wird eine 
TCP-Verbindung zum HTTP-Server 61' geof fnet' 62 : AnschlieSend 
sendet der HTTP-Client 60 einen Kommandostring an den HTTP- 
Server 61. Der HTTP-Server 61 antwortet uber die vom HTTP- 

25 Client 60 geoffnete TCP-Verbindung mit einem Kopf , der neben 
der vom HTTP-Server 61 unterstutzten HTTP-Version auch den 
MIME -Type und die Kodierung der angef orderten Datei enthalt. 
An diesen Kopf im ASCII-Format wird vom HTTP-Server 61 der 
Inhalt der angef orderten Datei angef ugt . Nachdem der HTTP- 

30 Server 61 die komplette Datei gesendet hat, schliefit dieser 
die vom HTTP-Client 60 geoffnete TCP-Verbindung wieder 63. 
Dieser Vorgang kann sich beliebig oft wiederholen. 
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Die folgende Zusammenstellung zeigt den Ablauf eines typi- 
schen HTTP-Zugrif f s : 

1. „ connect ion " (Verbindungsauf bau) 

• WWW-Client baut eine TCP/IP-Verbindung zum WWW-Server 
auf 

2. „request u (Anforderung) 

• Angabe einer Zugrif f smethode (GET, HEADER , POST...) 

• Spezif ikation des gewiinschten Dokumentes mittels URL 

• Zusatzinf ormationen in Form von MIME-Header 

• Daten (bei POST) 

3. response" (Antwort) 

• Header mit Statuscode 

• Zusatzinf ormationen in Form von MIME-Header 

• Dokument in HTML- Format 

• Daten in sonstigen Formaten (Bilder, Sound...) 

4. „close" (Verbindungsabbau) 

• Im Normalfall vom HTTP-Server aus , nach Datemibertra- 
gung 

• Im Spezialfall vom HTTP-Client aus (Ubertragungszeit , 
Speicherplatz) 

5 Hierbei besteht die „ request line" aus drei Textfeldern, wel- 
che durch Leerzeichen getrennt sind. Das erste Feld spezifi- 
ziert die Methode (oder das Kommando) . Das zweite Feld spe- 
zif iziert den Namen der Quelle (ist die URL ohne die Angabe 
des Protokolls und des Hosts) . Das letzte Feld spezif iziert 
10 die verwendete Protokoll vers ion des HTTP-Clients 60, bei- 
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spielsweise HTTP/1.0. Die ^request header fields" ubergeben 
zusatzliche Inf ormationen iiber die Anfrage und den HTTP- 
Client 60. Die Felder werden als eine Art RPC- Parameter be- 
nutzt. Jedes Feld besteht aus einem Namen, gefolgt von eine 
5 Doppelpunkt und dem Feldwert . Die Reihenfolge der „header 
fields" ist hierbei nicht wichtig. Der „ entity body" wird 
'manchmal von HTTP-Clients 60 verwendet, urn gro&ere Informati- 
onspakete an den HTTP-Server 61 zu senden. 

10 Dateicache 

Urn eine moglichst effiziente Arbeit der Cacheverwaltung 43 zu 
ermoglichen, arbeitet der Dateicache 45 nicht wie tiblich mit 
der URL, dem Datum und der Lebensdauer der zu verwaltenden 

15 Dateien, sondern nutzt weitere Kriterien zur Identif izierung 
einer Datei. Wiirden nur die drei genannten Kriterien fur den 
Entscheid verwendet werden, ob eine lokal im Dateicache vor- 
handene Datei mit der im Feldgerat verfugbaren Datei iden- 
tisch ist, dann ware fur die Durchfuhrung dieses Tests ein 

2 0 Vergleich der genannten Dateimerkmale erf orderlich . Dazu 

musste fur jede Datei der Kopf aus dem Feldgerat angefordert 
werden. Da das Dateisystem der Feldgerate FG1 . . . FGN jedoch 
nur als Einheit in Form eines KON-Dateien (konvertierte Da- 
teien - Format der in die Nutzereinrichtungen N1...NN ladba- 

25 ren Dateien) geladen werden kann, ist ein s'olcher Vergleich 

nicht fur jede Datei erf orderlich . Eine Ausnahme bilden hier 
die dynamisch in den Feldgeraten FG1 . . . FGN erzeugten Dateien, 
beispielsweise die Datei MLFB.TXT (MLFB - Maschinenlesbare 
Fabrikantenbezeichnung) , die nicht aus dem Dateisystem der 

30 Feldgerate FG1...FGM ausgelesen, sondern aus der im jeweili- 
gen Feldgerat FG1, . . . bzw. FGN eingestellten MLFB generiert 
wird. 
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Als Unterscheidungsmerkmal zwischen diesen beiden Dateifor- 
men, namlich den statischen Dateien und den Dateien mit dyna- 
mischen Daten, dient ein Eintrag in einer Datei „noca- 
che.txt M . Alle dynamisch in den Feldgeraten FG1...FGN er- 
5 zeugten Dateien miissen in dieser Datei aufgefuhrt sein. Sta- 
tische Dateien werden vom HTTP-Server HS1...HSN der Feldgera- 
te FG1...FGN mit einer unendlichen Lebensdauer gekennzeich- 
net. Im folgenden ist ein Beispiel fur den Inhalt der Datei 
„nocache . txt u gezeigt : 

10 

/mlfb.txt: MLFB , BF-Nr . , Displaytyp 

/textpool . zip: geratespezif ische Texte fur Applets 
(mehrsprachig) 
/ver . txt : Version, Datum 
15 /chartab. jar : Geratezeichensatz 

Die Datei „ ver. txt" kann hierbei den folgenden Inhalt aufwei- 
sen/anzeigen : 

20 VOL 01. 01 

Tue, 24 Oct 2000 07:50:00 GMT 

Slot-Protokoll des Proxyservers 

25 Das Slot-Protokoll 48 (vgl . Figur 8) dient der Anbindung des 
Proxyservers 1 an die Feldgerate FG1...FGN in einer Anordnung 
mit Sternkoppler nach Figur 7. Das Slot-Protokoll 48 glie- 
dert sich in die beiden Bereiche (i) Gerateerkennung und (ii) 
Arbitierung der Sternkoppleranordnung . Die Gerateerkennung 

3 0 dient der automatischen Erkennung aller an den Sternkoppler 
39 angeschlossenen Feldgerate FG1...FGN. Die Arbitierung 
muss Kollisionen von Datagrammen unterschiedlicher Feldgerate 
FG1. . . FGN auf der Kommunikationsverbindung zwischen dem Pro- 
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xyserver 1 und den einzelnen Feldgeraten FG1...FGN verhin- 
dern . 



Im folgenden wird die Gerateerkennung bei Nutzung der Stern- 
5 koppleranordnung 3 9 beschrieben. 



Gerateerk ennung 

Die Gerateerkennung stellt einen Bestandteil des Slot- 
10 Protokolls 48 dar. Dieser Protokollteil belegt die serielle 
Verbindung exklusiv, d. h. wahrend der Gerateerkennung darf 
keine andere Kommunikation auf der Modemstrecke aktiv sein. 
Deshalb wird die Gerateerkennung nur beim Aufbau der Modem- 
verbindung aktiviert. Im laufenden Betrieb des Beobachtungs- 
15 und Bediensystems ist dieser Protokollteil inaktiv. Die Ge- 
rateerkennung kann jedoch bei Bedarf aktiviert werden . 

Figur 10 zeigt eine Master-Slave-Anordnung mit Sternkoppler 
zur Erlauterung der Gerateerkennung. 

20 

Das Slot-Protokoll 48 arbeitet nach dem Master-Slave-Prinzip . 
Ein Master 70 befindet sich am oberen Anschluss in Figur 10. 
Die unteren Anschlusse eines Sternkopplers 71, • welcher dem 
Sternkoppler 3 in Figur 1 entspricht, werden von jewel Is ei- 

2 5 nem Slave SI. . . SN belegt, welche den Feldgeraten FG1 . * . FGN 

gemafi Figur 1 entsprechen. Der Master 70 konnte jede mogli- 
che Adresse der angeschlossenen Slaves SI . . . SN abf ragen und 
bei einer Antwort auf diese Anfrage den gefundenen Slave SI, 
. . . bzw. SN in die Liste der Gerate aufnehmen, die dem Master 

3 0 70 bekannt sind. Diese Vorgehensweise ist jedoch bei .einem 

Adressbereich von 32 Bit nicht mehr durchf uhrbar . Hier* waren 
2^32 Abf ragen erf orderlich. Diese Zahl ist jedoch nicht mehr 
durchf uhrbar , da hier die fur diese Abf rage erf orderliche 
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Zeit die Lebensdauer der Anlage liberschreiten wurde. Um den- 
noch die an den Master 70 angeschlossenen Gerate automatisch 
erkennen su kormen, wird das Problem erf indungsgemafi in der 
folgenden Weise gelost: 

5 

Bei einem Adressierungs schema mit einer Binar kodierten Ad- 
resse mit einer fest vorgegebenen Adresslange wird bei einer 
Anfrage immer ein Adressbereich abgef ragt . Auf diese Anfrage 
antworten nur die Slaves, die sich in dem abgef ragten Adress- 
10 bereich befinden. Da sich hier mehrere Feldgerate (Slaves) 
im gleichen abgef ragten Adressbereich befinden konnen, kommt 
es bei einer gleichzeitigen Antwort von mehreren der Slaves 
S1...SN in diesem Fall zwangslaufig zu einer Kollision. Die- 
se Kollision wird bewusst in Kauf genommen und ist Bestand- 
15 teil des vorgeschlagenen Verf ahrens . Aus diesem Grund pruf t 
der Master 70 nur, ob innerhalb eines definierten Zeitraums 
uberhaupt eine Antwort auf seine Anfrage eingegangen ist* 

Betragt der Adressraum der adressierbaren Slaves S1...SN n 
Bits, sendet der Master 70 jeweils eine Anfrage mit einem 
feststehenden Bit der Adresse und einer Maske fur die anderen 
Adressbits aus. Mit zwei Abfragen kann getestet werden, ob 
sich in dem durch das feststehende Bit vorgegebenen Adressbe- 
reich Slaves befinden. Wurde auf eine Anfrage fur einen Ad- 
ressbereich eine Antwort erhalten, dann wird die Maske um ein 
Bit verkleinert und fur das nachste feststehende Bit mit wie- 
derum zwei Abfragen getestet, ob sich in dem nun kleineren 
Adressbereich Slaves befinden. Kommt auf die Anfrage fur den 
nun kleineren Adressbereich eine Antwort, dann ist das nachs- 
te Bit des Adressbereichs gefunden, in dem sich Slaves befin- 
den. Dieser Vorgang wird so lange wiederholt, bis die Maske 
fur den Adressbereich sich auf 0 Bits reduziert hat. Dann 
ist einer der Slaves S1...SN am Bus eindeutig identif iziert . 
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Kommen bei einer Abfrage auf beide Zustande des gerade getes- 
teten Bits Antworten, dann werden beide Zweige in der nachs- 
ten Iteration weiter verfolgt. Da bei einer Maskengrofie von 
0 Bits nur das Gerat bzw. der Slave mit der angefragten, nun 
5 vollstandig f eststehenden Adresse auf die gestellte Anfrage 
antworten kann, konnen bei der letzten Anfrage auch keine 
Kollisionen mehr auftreten, und das Antworttelegramm der zu 
detektierenden Slaves kann spontane Inf ormationen uber den 
Zustand der angeschlossenen Slaves enthalten. Figur 12 erlau- 

10 tert das beschriebene Verfahren noch einmal anhand eines ein- 
fachen Adressierungs schema s mit einer 4 -Bit Adresse, also fur 
einen Adressraum vom 0 bis 15. Es wird vorausgesetzt , dass 
sich die Gerate mit den Adressen 3, 4 und 7 in der Anordnung 
befinden. Es wird mit der Abfrage vom hochstwert igeh Bit be- 

15 gonnen. Es wird also zum einen der Adressraum 0 bis 7 und in 
einer zweiten Abfrage der Adressraum 8 bis 15 mit einer Ab- 
fi~age getestet . Auf diese sweite Abfrage antwortet kein Ge- 
rat. Auf die erste Abfrage erhalt der Master eine oder mehre- 
re Antworten. Deshalb wird im Adressraum 0 bis 7 die Maske urn 

20 ein weiteres Bit verkleinert . Es werden also nun die Adress- 
bereiche 0 bis 3 mit einer dritten Abfrage und 4 bis 7 mit 
einer vierten Abfrage gepruft. Dieser Vorgang wiederholt sich 
entsprechend der Darstellung in Fig. 12 so lange, bis die Ad- 
ressen vollstandig aufgelost und damit alle Gerate gefunden 

25 sind. 

In dem beschriebenen Beispiel werden die Slaves SI. . .Sn bzw. 
die Feldgerate FG1...FGN mittels eines IP-basierten Proto- 
kolls an den Master 70 angeschlossen ; Beim IP-Protokoll ha- 
30 ben alle Busteilnehmer eine 32 Bit-Adresse. Die Adresse wird 
in Oktette aufgeteilt und jedes Oktett dezimal dargestellt. 
Die hexadezimale 32 Bit-Zahl Ox8D8D8000 entspricht also der 
IP-Adresse 141.141.128.0. Fur den eigentlichen Vorgang zur 
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Gerateerkennung/-abfrage wird eine rekursive Variante des im 
vorhergehenden Absatz beschriebenen Verfahrens verwendet . 

Pigur 11 zeigt das Ablauf diagramra des Verfahrens als Nassi- 
5 Sneidermann-Diagramm . 

Im Rahmen des beschriebenen Verfahrens wird der Test, ob ein 
Feldgerat (Slave) im verfugbaren Adressbereich ansprechbar 
ist, vorzugsweise mit Hilfe eines als solchen bekannten Re- 
guest -Datagrarams vom Master 70 ausgelost . Im Unterschied zu 
herkommlichen Verfahren wird jedoch bewusst in Kauf genommen, 
dass auf ein vom Master 70 ausgesandtes Reguest-Datagramm 
mehrere der Slaves S1...SN gleichzeitig antworten. Dadurch, 
dass im Sternkoppler 71 alle von den Slaves S1...SN empfange- 
nen Signale iiber ein logisches ODER-Gatter verkniipft werden 
und dieses Summensignal an den Master 70 weitergeleitet wird, 
kann sichergestellt werden, dass im Master 70 eine Antwort 
eines der Slaves S1...SN in jedem Fall erkannt wird. Wenn 
sich die Antwort -Datagramme mehrerer der Slaves S1...SN zeit- 
lich iiberlappen, wird im Master 70 ein fehlerhaftes Datagramm 
empfangen. Auch dieser Fall wird als Antwort erkannt. 

Mit Hilfe der Vorgabe einer maximalen Antwortzeit fur die 
Slaves S1...SN auf ein Request -Datagramm des Masters 70 und 
der Datagramm-Ubertragungszeit kann eine Uberwachungszeit fur 
den Master 70 definiert werden. Erhalt der Master 70 inner- 
halb dieser Uberwachungszeit eine Antwort, dann befinden sich 
im angefragten Adressbereich Slaves bzw. Feldgerate. Im Um- 
kehrschluss befinden sich im angefragten Adressbereich keine 
Feldgerate, wenn vom Master 70 innerhalb der Uberwachungszeit 
keine Antwort auf den Request empfangen wurde . 
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Da bei einer vollstandigen Auflosung der Adresse im Request 
des Maters 70 (d.h. die Maske wird leer) nur noch einer der 
Slaves S1...SN antworten darf, kann in diesem Fall auch keine 
Kollision mehr auftreten. Damit kann in diesem Fall die Feh- 
5 lersicherung des empfangenen Datagramms benutzt werden, urn 
eine Leitungsstorung und damit eine mogliche Fehlerkennung 
eines angeschlossenen Slaves auszuschlieSen. Tritt wahrend 
der Uberwachungszeit nach einem Request des Masters eine Lei- 
tungsstorung auf , die einen nicht vorhandenen Slave vor- 

10 tauscht, fuhrt das nur zu einer Verlangerung des Vorgangs zum 
Abfragen, aber. nicht zu einer falschen Erkennung von ange- 
schlossenen Slaves, da diese Leitungsstorung spatestens bei 
der vollstandigen Auflosung der Maske erkannt wird. 
Der folgende Absatz zeigt anhand eines Beispiels die Funktion 

15 des Verf ahrens : 



Test : 


141. 


141 . 


128. 0 


Mask : 


255 


.255 


. 128 


.0 


Test : 


141. 


141 . 


0 . 


0 


Mask: 


255 


.255 


. 128 


.0 


Test : 


141. 


141 . 


64 


. 0 


Mask : 


255 


.255 


.192 


.0 


Test : 


141. 


141 . 


96 


. 0 


Mask: 


255 


.255 


.224 


.0 


Test : 


141. 


141. 


64 


. 0 


Mask: 


255 


.255 


.224 


.0 


Test : 


141. 


141. 


80 


. 0 


Mask: 


255 


.255 


.240 


.0 


Test : 


141. 


141 . 


88 


. 0 


Mask : 


255 


. 255 


. 248 


.0 


Test : 


141. 


141 . 


80 


. 0 


Mask : 


255 


.255 


. 248 


.0 


Test : 


141. 


141 . 


84 


. 0 


Mask: 


255 


.255 


.252 


.0 


Test : 


141. 


141 . 


86 


. 0 


Mask: 


255 


.255 


.254 


.0 


Test : 


141. 


141 . 


84 


. 0 


Mask : 


255 


.255 


.254 


.0 


Test : 


141. 


141 . 


85 


. 0 


Mask: 


255 


.255 


.255 


. 0 


Test : 


141. 


141. 


84 


. 0 


Mask: 


255 


.255 


.255 


.0 


Test : 


141. 


141. 


84 
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Mask: 


255 


. 255 


.255 


.128 


Test : 


141 . 


141. 


84 


.0 


Mask: 


255 


.255 


.255 


.128 


Test : 


141 . 


141 . 


84 


.64 


Mask: 


255 


.255 


.255 


.192 


Test : 


141 . 


141. 


84 


. 0 


Mask: 


255 


.255 


. 255 


.192 


Test : 


141. 


141. 


84 


.32 


Mask : 


255 


.255 


.255 


.224 
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Test : 


141 . 


141 . 


84 


. 0 


Mask : 


255 


.255 


.255 


. 224 




Test : 


141 . 


141 . 


84 


. 16 


Mask : 


255 


. 255 


. 255 


. 240 




Test : 


141 . 


141 . 


84 


. 0 


Mask : 
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255 


. 255 


o rr r 

. 255 


. 240 




Test : 


141 . 


141 . 


84 


. 8 


Mask : 


rv r r 

255 


.255 


o r r 

.255 


o a a 

. 248 


5 


Test : 


141 . 


141 . 


84 


. 0 


Mask : 


255 


.255 


. 255 


O A O 

. 248 




Test : 


141 . 


141 . 


84 


. 4 


Mask : 
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255 
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.255 


o r r 

.2 55 


o r o 

. 2 52 




Test : 


141 . 


141 . 


84 


. 0 


Mask : 


o r r 

255 


. 255 


ore* 

. 255 


o r o 

. 252 




Test : 


141 . 


141 . 


84 


. 2 


Mask : 


255 


. 255 


. 255 


. 254 




Test : 


141 . 


141 . 


84 


. 3 


Mask : 


255 


ore 

. 255 


o r r 

. 255 


orr 

. 2 55 


10 


Test : 


141 , 


141 . 


84 


. 2 


Mask : 


255 


o r r 

. 255 


o r r 

. 255 


orr 

. 2 55 




Found : 


141 . 


141 . 


84 


. 2 














Test : 


141 . 


141 . 


84 


. 0 


Mask : 


255 


.255 


ore 

. 255 


o r a 

. 254 




Test : 


141 . 


141 . 


80 


. 0 


Mask : 


255 


o r* P" 

.255 


. 252 


. 0 




Test : 


141 . 


141 . 


82 


. 0 


Mask : 


255 


. 255 


. 254 


. 0 


15 


Test : 


141 . 


141 . 


80 


. 0 


Mask : 


o r - r - 

255 


.255 


o r A 

. 254 


. 0 




Test : 


141 . 


141 . 


81 


. 0 


Mask : 


o r r 

255 


.255 


Orr 

.255 


. 0 




Test : 


"1 A *1 

141 . 


141 . 


80 


. 0 


Mask : 


o tr tr 

255 


nr r 

. 255 


o rr c 

. 255 


. 0 




Test : 


141 . 


141 . 


o o 

8 0 


. 12 8 


Mask : 


255 


o r r 

. 255 


Orr 

.25 5 


TOO 

. 12 8 




Test : 


*i a n 

141 . 


i A n 

141 . 


80 


"1 O O 

. 192 


Mask : 


ore 

255 


o r r 

.255 


orr 

.255 


1 o o 

. 192 


o o 

2 0 


Test : 


141 . 


"1 A "1 

141 . 


8 0 


•i o o 

. 128 


TV/I — f-m 1j- 

Mask : 


255 


ore* 

. 255 


.255 


too 

. 192 




Test : 


-1 a *i 

141 . 


141 . 


80 


. 160 


Mask : 


255 


ore* 

.255 


orr 

.255 


O O A 

. 224 




Test : 


141 . 


1 A t 

14 1 . 


8 0 


. 176 


Mask : 


Ore 

255 


o r r 

. 255 


orr 

.255 


O A f\ 

. 240 




Test : 


1 A *1 


14 1 . 


8 0 


. 16 0 


Mask : 


o rr r 
2 55 


Or r- 

.255 


Orr 

. 255 


o a r\ 

. 24 0 




Test : 


1/11 

141 . 


141 . 


o /o 

8 0 


. 168 


Mask : 


255 


O r r 

. 255 


orr 

. 255 


o a o 

. 24 8 


25 


Test : 


"I /I "1 

141 . 


1 A *1 

141 . 


o o 

8 0 


"I /*" O 

. 160 


Mask : 


orr 

255 


orr 

. 255 


orr 

. 255 


. 248 




Test : 


141 . 


141 . 


80 


. 164 


Mask : 


255 


. 255 


. 255 


. 252 




Test : 


141 . 


141 . 


80 


. 166 


Mask : 


255 


. 255 


. 255 


. 254 




Test : 


141 . 


141 . 


80 


. 164 


Mask : 


255 


. 255 


. 255 


.254 




Test : 


141. 


141. 


80 


.165 


Mask: 


255 


.255 


. 255 


.255 


30 


Test : 


141. 


141. 


80 


.164 


Mask : 


255 


.255 


.255 


.255 




Found : 


141. 


141. 


80 


.164 














Test : 


141. 


141. 


80 


.160 


Mask : 


255 


.255 


.255 


.252 




Test : 


141. 


141. 


80 


.162 


Mask: 


255 


.255 


.255 


.254 
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Test : 


141 . 


141 . 


80 


. 163 


Mask: 


255 


. 255 


. 255 


. 255 


Found : 


141 . 


141 . 


80 


.163 












Test : 


141. 


141 . 


80 


.162 


Mask: 


255 


.255 


.255 


. 255 


Test : 


141 . 


141. 


80 


.160 


Mask: 


255 


.255 


.255 


. 254 


Test : 


141 . 


141 . 


80 


.161 


Mask: 


255 


.255 


. 255 


. 255 


Found : 


141 . 


141 . 


80 


. 161 












Test : 


141. 


141 . 


80 


. 160 


Mask: 


255 


.255 


.255 


. 255 


Found : 


141 . 


141 . 


80 


. 160 












Test : 


141 . 


141 . 


80 


. 128 


Mask: 


255 


.255 


.255 


. 224 


Test : 


141 . 


141 . 


80 


. 0 


Mask: 


255 


.255 


.255 


. 128 


Test : 


141. 


141 . 


64 


. 0 


Mask: 


255 


.255 


. 240 


. 0 


Test : 


141. 


141 . 


0. 


0 


Mask: 


255 


.255 


. 192 


. 0 


58 Abfragen . . . 

















15 Die Abfragen schlossen den Adressraum 141.141.0.0 bis 

141.141.255.255 ein. Es wurden die Gerate mit den folgenden 

Adressen gefunden: 

141.141.84.2 

141.141.80.164 

141.141.80.163 

141.141.80.161 

141 . 141 . 80. 160 

Figur 12 illustriert den dargestellten Vorgang in Form einer 
20 Baumdarstellung, wobei die fett umrandeten Felder die Abfra- 
gen kennzeichnen, die von einem oder mehreren Slaves SI ... SN 
bzw. Feldgeraten beantwortet wurden. 

Broadcast -Dienst 

25 

Fur die Anbindung des Proxyservers 1 an die Feldgerate 
FG1...FGN kann anstelle der einfachen Architektur mit Stern - 
koppler 3 9 ein IP-basiertes Netzwerk genutzt werden. In die- 
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sem Fall ist eine Arbitierung dieses Netzwerks durch ein Pro- 
tokoll, beispielsweise das Slot-Protokoll 48, nicht erforder- 
lich. Diese Funktion ubernimmt das Netzwerk selbst . Fur die 
Gerateerkennung konnen bei dieser Ausf iihrungsf orm ebenfalls 
5 Funktionen des Netzwerks genutzt werden. Bei einer Netzwerk - 
verbindung zwischen dem Proxyserver 1 und den Feldgeraten 
FG1...FGN wird sur Selbstkonf igurierung des Beobachtungs - und 
Bediensystems ein Broadcast-Dienst benutzt. 

10 In beiden Fallen des Erkennens der angeschlossenen Feldgerate 
FG1...FGN, d.h. bei der Ausf iihrungs form mit Sternkoppleran- 
ordnung und bei Nutzung eines Netzwerks, insbesondere eines 
LANs, wird das Erkennen bei Inbetriebsetzung des Beobach- 
tungs- und Bediensystems automatisch ausgefuhrt und erfolgt 

15 ohne vorherige Parametrierung der am System beteiligten Kom- 
ponenten. 

Der Broadcast-Dienst dient zum Erkennen der an das IP- 
basierte Netzwerk (z. B. LAN) angeschlossenen Feldgerate, die 

2 0 einen Server fur ihre eigene Bedienung enthalten. Weiterhin 

dient der Broadcast-Dienst zum Einsammeln von in den ange- 
schlossenen Feldgeraten auf getretenen spontanen Ereignissen . 
Der Broadcast-Dienst ist eine IP-Applikation und basiert so- 
mit auf den Funktionen des IP-Stacks und setzt auf dem UDP- 
25 Protokoll auf. Fur diesen Dienst wird Serverseitig z. B. ein 
fest vorgegebener Port OxDOOO reserviert. Clientseitig wird 
dynamisch ein f reier Port ausgewahlt . Durch den Einsatz des 
Standard-UDP/lP-Protokolls kann hier auf den IP-Programmier- 
schnittstellen von ublichen Betriebssystemen, wie z. B. MS- 

3 0 Windows oder Linux, aufgesetzt werden. Damit kann der Proxy- 

server 1 problemlos auf klassische Buroserver portiert wer- 
den. 
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Der Broadcast -Dienst ist sowohl im Proxyserver 1 als auch in 
den einzelnen Feldgeraten aktiv. Fur den Broadcast-Dienst 
wird der Proxyserver 1 als Master festgelegt. Eine Konfigu- 
rationsabf rage ist ein vom Master abgesendetes UDP-Telegramm. 
Dieses Telegramm richtet sich je nach Konf iguration an eine 
Broadcast- oder eine Multicast- IP-Adresse . Eine Beschreibung 
von Broadcast- oder Multicast- IP- Adressen findet sich bei- 
spielsweise in Karanjit S. Siyan: Inside TCP/IP Third Editi- 
on, New Riders Publishing, Indianapolis, 1997, ISBN 1-56205- 
714-6, Seite 187ff . 

Alle Feldgerate werden anschlieSend auf die Konf igurationsab- 
frage des Masters mit einem UDP-Telegramm antworten, welches 
die wichtigsten Konf igurationsdaten des Feldgerats enthalt . 
Da jetzt alle an dem IP-basierten Netzwerk angeschlossenen 
Feldgerate theoretisch gleichzeitig Antworten mochten, wird 
es zunachst zu einigen Kollisionen auf dem genutzten Bus kom- 
men, die durch das CSMA/CD-Verf ahren (CSAM - „ carrier sense, 
multiple access/collision detect") aufgelost werden. Eine 
Beschreibung dieses Verfahrens ist ebenfalls in Karanjit S. 
Siyan: Inside TCP/IP Third Edition, New Riders Publishing, 
Indianapolis, 1997, ISBN 1-56205-714-6, Seite 97ff zu fin- 
den. Die UDP- Ant wort telegramme aller aktiven Feldgerate wer- 
den also beim abfragenden Master innerhalb einer gewissen 
Zeit ankommen. Somit ist der Abfragende in der Lage festzu- 
stellen, wie viele und welche Feldgerate sich im Netzwerk be- 
finden, und kann anschlieSend von den Feldgeraten weitere In- 
formationen iiber das HTTP- Pro tokoll oder andere IP-basierte 
Protokolle anfordern. 

Der Broadcast -Dienst hat auSerdem noch die Aufgabe, ein spon- 
tan in einem der Feldgerate auflaufendes Ereignis im IP- 
basierten Netzwerk an die Teilnehmer des Broadcast -Dienstes 
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zu verteilen. Da die Feldgerate einerseits keine Information 
daruber besitzen, welcher Master fur dieses Signal zustandig 
ist und es andererseits moglich sein kann, das im IP- 
basierten Netzwerk mehrere Master mit verteilten Aufgaben e- 
5 xistieren, wird das Ereignistelegramm als Broadcast an alle 
Netzwerkteilnehmer gesendet . Die Master konnen dieses Signal 
je nach Ereignistyp und Sender ignorieren oder eine Aktion 
auslosen, welche liber ein weiteres Protokoll, z. B. HTTP, zu- 
satzliche Inf ormationen von dem Feldgerat abruf t . Dieses Ab- 

10 rufen zusatzlicher Inf ormationen am das Ereignis aussendenden 
Feldgerat durch den zustandigen Master dient gleichzeitig als 
Empf angsbestatigung des Masters. Wird ein Ereignistelegramm 
nicht bestatigt, dann wird es solange in regelmaSigen Abstan- 
den (beispielsweise etwa 10 s oder mit einer logarithmisch 

15 wachsenden Zeit) wiederholt bis eine Bestatigung von einem 
Master stattf indet . 

Figur 13 zeigt eine schematische Darstellung zur Erlauterung 
des Verfahrens im Rahmen der Konf igurationsabf rage . 

20 

Der Proxyserver 1 sendet als Master eine Konf igurationsanf ra- 
ge 72 als Broadcast an alle Teilnehmer im Netzwerk. Alle 
Feldgerate FG1...FGN antworten mit einem UDP-Datagramm an die 
IP-Adresse des Masters, der die Konf igurationsanf rage ausge- 
25 sandt hat. Dieses UDP-Datagramm enthalt wie bereits darge- 

stellt die wichtigsten Inf ormationen uber die angeschlossenen 
Gerate . 

Gerateve r wa 1 1 ung 

30 

Die Verwaltung der mit Hilfe der Gerateerkennung bei Nutzung 
des Sternkopplers 3 9 oder des Broadcast -Dienstes erkannten 
Feldgerate bzw. Slaves erfolgt im Proxyserver 1 mit Hilfe der 
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Gerateverwaltung 49 (vgl . Figur 8). Figur 14 zeigt ein sche- 
matisches Blockdiagramm der Anbindung der Gerateverwaltung 49 
im Proxyserver 1 . 

5 Die Gerateverwaltung 4 9 stellt der Cacheverwaltung 43 und der 
XML-Datenbank 50 Inf ormationen fiber die im Geratenetzwerk er- 
kannten Feldgerate FG1...FGN zur Verfugung. Dazu bezieht die 
Gerateverwaltung 49 ihre Inf ormationen uber die angeschlosse- 
nen Feldgerate FG1 . . . FGN aus dem im Rahmen des Slot- 

10 Protokolls 48 ablaufenden Verf ahrens . Auf diese Weise werden 
die IP-Adressen der angeschlossenen Feldgerate FG1 . . . FGN be- 
reitgestellt . Die Gerateverwaltung 49 wird vom Slot- 
Protokoll 4 8 mit den Inf ormationen uber die erkannten Feldge- 
rate FG1...FGN versorgt. Das Slot-Protokoll 48 liefert der 

15 Gerateverwaltung 4 9 nur die IP-Adressen der erkannten Feldge- 
rate FG1...FGN. Alle weiteren Inf ormationen uber die Feldge- 
rate FG1...FGN, die durch die Gerateverwaltung 49 im Proxy- 
server 1 bereitzustellen sind, werden mit des Herunterladens 
von HTTP-Daten in festgelegten Dateien aus den Feldgerate r 

20 FG1...FGN beschafft. Die Gerateverwaltung 49 stellt mit Hil- 
fe der bekannten IP-Adressen aller erkannten Feldgerate 
FG1 . . . FGN der Cacheverwaltung '43 die' folgenden Irif ormationen 
uber die Feldgerate FG1...FGN zur Verfugung: Feldgerate-Typ, 
Feldgerate-Version und Version des Dateiblocks fur das Beo- 

25 bachtungs- und Bediensystem. 

Im Dateicache 45 (vgl. Figur 8) sind diese Inf ormationen fur 
die dor t bereits gespeicherten Dateien ebenfalls vorhanden. 
Damit kann bei einer Anforderung einer Datei von einem be- 
30 stimmten der Feldgerate FG1...FGN anhand dieser Inf ormationen 
entschieden werden, ob die im Dateicache 45 vorliegende Datei 
mit der in dem Feldgerat verfugbaren Datei identisch ist, oh- 
ne den Dateikopf der angef orderten Datei aus dem bestimmten 



BNSDOCID: <WO 03036400A1_I_> 



WO 03/036400 



PCT/DE02/03849 



46 

Feldgerat zu lesen, Es tmissen nur die im Dateicache 45 vor- 
liegenden Ver s ionsinf ormat ionen fur die Datei mit den Infor- 
mationen aus der Gerateverwaltung 49 fur die IP-Adresse des 
bestimmten Feldgerats verglichen werden. 

5 

Die Anbindung der Gerateverwaltung 4 9 an die XML-Datenbank 5 0 
dient der Bereitstellung von Informationen aus den Feldgera- 
ten FG1...PGN. Diese Informationen werden in Form einer XML- 
Datei aus den Feldgeraten FG1...FGN geladen. Die folgende 
10 Tabelle zeigt eine Ubersicht liber die Inhalte dieser Datei: 



Information 


Tag 


Beschreibung 


Geratetyp 


DEVJTYPE 


Stellen 1..6 der MLFB 


MLFB 


MLFB 


vollstandige MLFB des Gerates 


BF-Nummer 


BF_NR 


Geratekennung (, , unique number") 


Ver- 




VER_KEYS 


Liste von Versionsschlusseln 


sion 


Datei- 
system 


VERSION 


Datum und Versionsnummer des Da- 
teisystems 




Firmwa- 
re 


VERSION 


Datum und Versionsnummer der Gera- 
tef irmware 




System- 
firmwa- 
re 


VERSION 


Datum und Versionsnummer der im 
Gerat verwendeten Systemf irmware 


„non ca- 
cheable" Da- 
teien 


NOCACHE 


Liste aller Dateien, die immer di- 
rekt vom Gerat geholt werden miis- 
sen 


Memibaum 


MENU 


Geratebedienbaum zur Einbettung in 
den Proxyserver-Bedienbaum 


Prozessdaten 


DATA_OBJ 


Liste der XML-Dateien, die alle 
vom Gerat lieferbaren Prozessdaten 
beschreiben 
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Alle diese Informationen werden in einer Datei „DevData .xml w 
gespeichert. Die Gerateverwaltung 4 9 veranlasst ein HTTP- 
Herunterladen dieser Datei, wenn eines der Feldgerate 
FG1...FGN vom Slot-Protokoll 48 gefunden wurde. Alle weite- 
5 ren Dateien werden von der Gerateverwaltung 4 9 nur dann aus 
dem Feldgerat geladen, wenn deren Dateipfad in dieser XML- 
Datei enthalten ist, d.h. es werden alle mit einem 
<DEV_PATH>-Tag gekapselten Dateien geladen. 

10 Die Datei ;/ DevData.xml u wird im Proxyserver 1 nach dem Herun- 
terladen mit Hilfe des XSL-Parsers 54 in das interne Format 
des Proxyservers 1 transf ormiert und anschlieteend in der XML- 
Datenbank 5 0 des Proxyservers 1 eingetragen. 

15 XSL-Parser 

Der XSL- Parser 54 (vgl . Figur 8) dient der Erzeugung von dy- 
namisch generierten HTML -Dateien aus der zentralen XML- 
Datenbank 50 des Proxyservers 1. Dazu werden lokal im Proxy - 
20 server 1 abgelegte XSL-Scripte benutzt. Die XSL-Scripte kon- 
nen mit Hilfe einer Admin-Seite in den Proxyserver 1 einge- 
spielt werden. 

Figur 15 zeigt die Einbindung des XSL-Parsers 54 in dem Pro- 
25 xyserver 1. 

Wird uber den HTTP-Server 40 eine XMl -Datei von den Nutzer- 
einrichtungen N1...NN aus dem Intranet angefordert, dann wird 
diese Anforderung vom Datei-Filter 42 ausgef iltert und. an das 
30 XML -Front -end HTTP 55 weitergeleitet . Dieses Front-end sucht 
eine zur angef orderten XML-Datei gehoriges XSL- 
Transformationsscript und startet den XSL-Parser 54 mit die- 
sen beiden Dateien. 
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Da dynamisch generierte HTML-Seiten die verwendeten Daten im- 
mer aus der lokal im Proxyserver 1 liegenden XML-Datenbank 50 
verwenden, muss der Inhalt dieser Datenbank mit den in den 
Geraten vorhandenen Daten abgeglichen werden. Dieser Ab- 
gleichprozess ist deshalb erf orderlich, da viele in der XML- 
Datenbank 50 abgelegen Daten wie z. B. Messwerte zeitveran- 
derlich sind. Diesen Abgleich ubernimmt der Block XML-Front - 
end RPC-Cache 57. Bei einem Zugriff vom XSL-Parser 54 auf die 
XML-Datenbank 50 wird vom zwischengeschalteten XML -Front -end 
57 die Gultigkeitsdauer der angef orderten Information uber- 
pruft. Ist die angef orderte Information bereits ungiiltig ge- 
worden, dann wird sie von der- Verbindungsverwaltung 52 neu 
aus dem RPC-Client 53 aus dem Gerat angef ordert, in der XML- 
Datenbank 50 aktualisiert und an den XSL-Parser 54 weiterge- 
leitet . 

Die Gerat eve rwaltung 4 9 liberwacht fort lauf end den Status der 
am Geratenetzwerk angeschlossenen Gerate und aktualisiert 
diese Inf ormationen mittels des XML-Front-end Geratedaten 56 
in der XML-Datenbank 50. 

Der XSL-Parser 54 ist das Hauptbindeglied bei der Darstellung 
der aktuellen, von den Feldgeraten FG1 . . . FGN empfangenen Da- 
ten aus der XML-Datenbank 50. Jedes XSL-Script gibt Trans- 
f ormationsregeln vor, die festlegen, in welcher Weise be- 
st immte Daten aus der XML-Datenbank 5 0 in Form von HTML- 
Seiten in den Nutzereinrichtungen N1...NN anzuzeigen sind. 
Eines der Grundprinzipien von XML ist die Trennung von Inhalt 
und Presentation. Ein XML-Dokument enthalt nur * Inhalt * , sei- 
ne Presentation muss, in Form eines Stylesheets , gesondert 
definiert werden. Es gibt verschiedene Moglichkeiten die Dar- 
stellungsinf ormation zu einem XML-Dokument hinzuzuf ugen . Die- 
se beruhen auf zwei Grundverf ahren: Entweder wird das Doku- 
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merit gemaS eines Stylesheets in eine darstellbare Form ge- 
bracht oder das Stylesheet leitet den Darstellungsmechanismus 
dabei an, wie die einzelnen Elemente des Dokuments darzustel- 
len sind. Diese beiden Grundverf ahren konnen in verschiedener 
5 Weise variiert werden: 

- CSS-Stylesheet + XML-Dokument XML-f ahiger Browser 

Der Browser verarbeitet das Dokument und die Darst el lungs - 

informationen in Form eines CSS-Stylesheets und erzeugt 

eine Presentation . 
10 - XSL-Stylesheet + XML-Dokument XSL-f ahiges Darstellungs- 

programm 

Ein Darstellungsprogramm, das XSL-Stylesheets verarbeiten 
kann, erhalt neben dem Dokument die Prasen- 
tationsinformation in Form eines XSL-Stylesheets. 
15 - XSL-Stylesheet + XML-Dokument XSL-Transf ormator — > HTML- 
Dokument 

Das XML-Dokument wird entsprechend der Transf ormationsre- 
geln eines XSL-Stylesheets von einem XSL-Transf ormator in 
ein (X) HTML-Dokument transf ormiert , das dann von einem 

2 0 Browser dargestellt werden kann. 

Figur 16 zeigt ein schematisches Blockschaltbild eines XSLT- 
Prozessors (XSL - „Extended Stylesheet Language Transformati- 
on") . 

25 

Das in Figur 16 dargestellte Blockschaltbild verdeutlicht 
noch einmal den Datenfluss, wenn eine XML-Datei angefordert 
wird. Die vom Client angeforderte Datei Xview.XML wird vom 
HTTP-Server an den XSLT-Prozessor 54 weitergeleitet . Dieser 

3 0 sucht die zur angefordert en Datei Xview.XSL gehorige Datei 

Xview.XSL und startet den XSLT-Prozessor 54 mit diesen beiden 
Dateien. Soil in dem liber die angeforderte Datei Xview.XML 
gestarteten Transf ormationsprozess Prozessdaten aus der XML- 
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Datenbank 5 0 des Proxyservers verwendet werden, dann muss das 
Transf ormationsscript Xview.XSL einen Verweis auf diese Da- 
tenbank enthalten. In dem in Figur 16 dargestellten Beispiel 
hat diese XML-Datenbank 50 den Namen Siprogate . XML . 

5 

Da alle mit Hilfe der Nutzereinrichtungen Nl . . .NN angezeigten 
Inf ormationen bei ihrer Anforderung einen XSLT-Prozessor 
durchlaufen, ist es zweckmaSig, die hierbei angef orderten In- 
f ormationen wie bereits beschrieben mit Hilfe des XML- Front - 

10 ends RPC-Cache 57 auf ihre Gultigkeit zu prufen und das Re- 
sultat fur einen Aktualisierungsmechanismus zu verwenden. 
Hierzu muss der XSLT-Parser so manipuliert werden, dass fest- 
gestellt werden kann, welche Daten aus den einzelnen Daten- 
banken bei der Gestaltung der zu erzeugenden HTML-Seite be- 

15 teiligt sind. Anhand dieser Information wird dann in einem 
zweiten Schritt f estgestellt , ob diese Daten aktuell sind. 
Daraufhin werden die dazu erf orderlichen Aktualisierungsme- 
chanismen angestoSen, sofern dies notwendig ist, und im An- 
schluss der Parservorgang noch einmal gestartet, wobei immer 

20 nur jene Daten aktualisiert werden, die gegenwartig in jegli- 
cher Form einem Benutzer mit Hilfe einer oder mehrerer der 
Nutzereinrichtungen N1...NN angezeigt werden. Das wird da- 
durch erreicht, dass nur die angef orderten Daten in der XML- 
Datenbank aktualisiert werden. Aufgrund der moglicherweise 

25 erheblichen GesamtgroSe der XML-Datenbank 50 ergibt sich mit 
Hilfe dieses Mechanismus eine Reduzierung der zwischen den 
Feldgeraten FG1...FGN und dem Proxyserver 1 ubertragenen Da- 
ten, da einerseits nur auf Anforderung und andererseits immer 
nur die fur die jeweilige Darstellung erf orderlichen Daten 

3 0 geholt werden. 
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Patentanspruche 

1. verfahren zur Inbetriebnahme eines Bedien- und Beobachtungs - 
systems fur Feldgerate (N1...NN), wobei in den Feldgeraten 
5 (N1...NN) jeweils eine Servereinrichtung ausgebildet ist und 

die Feldgerate (FG1...FGN) an eine Proxy-Servereinrichtung (1) 
angeschlossen sind und wobei die Proxy-Servereinrichtung (1) 
mit einer Nutzereinrichtung (Nl, NN) verbunden ist, auf 

welcher eine Browser-Einrichtung installiert ist, das Verfah- 
10 ren die folgenden Schritte aufweisend: 

- Ausfuhren einer Abfrage der Feldgerate (FG1...FGN) durch 
die Proxy-Servereinrichtung (1) zum automat ischen Erkennen 
der an die Proxy-Servereinrichtung (1) angeschlossenen 
Feldgerate (FG1. . . FGN) ; 

15 _ Erfassen einer jeweiligen Netzwerkadresse fur die Feldgera- 

te (FG1...FGN) durch die Proxy-Servereinrichtung (1); und 

- Erzeugen einer Basisinf ormation durch die Proxy-Server- 
einrichtung (1), wobei die Basisinf ormation in Abhangigkeit 
von der Abfrage der Feldgerate (FG1...FGN) jeweilige elekt- 

20 ronische Inf ormationen iiber die Feldgerate (FG1...FGN) um- 

fasst und wobei die jeweiligen elektronischen Inf ormationen 
eine Link- Information auf die jeweilige Servereinrichtung 
der Feldgerate (FG1...FGN) umfassen. 

25 2. Verfahren nach Anspruch 1, 

dadurch gekennzeichnet, dass 

die Link- Information ausgebildet ist, so dass nach einem Uber- 

mitteln der Basisinf ormation an die Nutzereinrichtung (Nl, 

NN) mit Hilfe der Browser-Einrichtung jeweilige Geratein- 

3 0 f ormationen zum Beobachten/Bedienen der Feldgerate (FG1...FGN) 

grafisch ausgegeben werden, die von der jeweiligen Serverein- 
richtung der Feldgerate (FG1...FGN) abrufbar sind. 

3 . Verfahren nach Anspruch 1 oder 2 , 
35 dadurch gekennzeichnet, dass 
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die Basisinf ormationen in einer Speichereinrichtung (50) der 
Proxy - S erver e inr i chtung (1) gespeichert wird. 

4. Verfahren nach einem der vorangehenden Anspruche, 
dadurch gekennzeichnet, dass 
Basisinf ormationen eine jeweilige Alarms tatusinformation 
fur die Feldgerate (FG1...FGN) umfassen. 

5. Verfahren nach einem der vorangehenden Anspruche, 
dadurch gekennzeichnet, dass 
Basisinf ormationen elektronische Daten zum automat ischen 
Erzeugen eines graf isch ausgebbaren Bedienbaums mittels 
der Browsereinrichtung nach dem Ubermitteln der Basisin- 
formation von der Proxy- Servere inr i chtung (1) an die Nut- 
zereinrichtung (Nl, . . . , NN) umfassen. 

6. Verfahren nach einem der vorangehenden Anspruche, 
dadurch gekennzeichnet, dass 
die Abfrage der Feldgerate (FG1...FGN) durch die Proxy- 
Servereinrichtung (1) zum automat ischen Erkennen der an 
die Proxy-Servereinrichtung (1) angeschlossenen Feldgera- 
te (FG1 . ♦ . FGN) mit Hilfe einer „broadcast U -Anf rage ausge- 
fiihrt wird. 



7. Verwendung eines Verfahrens nach einem der Anspruche 1 
bis 6 zur Inbetriebnahme eines Bedien- und Beobachtungs- 
systems fur Feldgerate in energietechnischen Anlagen. 
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Abstract of WO03036400 

The invention relates to a method for 
implementing an operating and observation 
system for field devices (FG1-FGN). A server 
device (HS1-HSN) is provided in each field 
device and the field devices are connected to a 
proxy server device (1). Said proxy server device 
is connected to a user device (N1-NN) on which 
a browser device is installed. The proxy server 
device interrogates the field devices in order to 
automatically identify the field devices which are 
connected to the proxy server device, and 
allocates a network address to each field device. 
A basic information message is produced by the 
proxy server device, said information message 
comprising specific electronic information about 
each field device, based on the results of the 
interrogation thereof. The respective electronic 
information comprises link information concerning 
the respective server device of each field device, 
such that after the basic information message 
has been transmitted to the user device, 
respective device information messages are 
emitted in a graphical manner, by means of the 
browser device, for the observation/operation of > r* 

~~the*field w devicesr Said-device information 

messages can be requested from the respective 

*~~server devices^ofthe field devices. 
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